'Today' considers data retention and IMP

John Lamb ukcrypto at chiark.greenend.org.uk
Tue, 13 Jan 2009 15:52:11 +0000


On Tue, Jan 13, 2009 at 02:10:32PM +0000, Ian Batten wrote:
> >
> >(2) I'm not convinced the certificate check IS dealing with a  
> >different
> >   risk.  The very people most likely to have the ability to passively
> >   sniff *backbone* links are probably ISP staff, who could just as  
> >easily
> >   mount an active attack to defeat opportunistic TLS.  E.g redirect  
> >SMTP
> >   to a transparent proxy, effectively man-in-the-middle'ing the TLS.
> 
> That's a much harder attack to mount, though.  For a two blokes ISP  
> it's do-able, but it would require co-ordination across quite a wide  
> range of functions with a larger undertaking.  It'd be something an  
> ISP undertook, not an ISP employee.
> 
> It'd also be fairly easy to spot.  You strew about on other machines  
> you control self-signed certificates which you can verify, and use  
> those as canaries in the mine.

If you were going to MitM SMTP connections, wouldn't it be easier to
force plaintext rather than spoof certificates? It would also have the
benefit of looking more like an innocuous configuration error rather
than an evil interception.

Either way, you shouldn't need more than access to a single router in
the right place to do it. The difficulty in compromising routers is the
main protection against this, but there have been a few demonstrations
over the years e.g. IOS shellcode. If you had this capability in place I
expect you would only activate it very, very rarely - you could get
traffic analysis all the time and switch on the (detectable) MitM when
you really need it.