Nepal and proxies

[Billy Crook]

On Tue, Jul 15, 2008 at 09:25, Charles Steinkuehler
<charles at steinkuehler.net> wrote:
> You need to look at the certificate of the site you're talking to.

Don't we always do that?

> It's possible to proxy/NAT/mangle https traffic w/o listening in on the
> encrypted communication.  It's also possible to do a man-in-the-middle
> decrypt/re-encrypt of the traffic to sniff the contents.

You could proxy it and pass it on without modification, getting
information from traffic shape and access times to deduce what's going
on, but this would be very difficult and not very useful.  You can
certainly NAT https.  That's of little importance.  You can not
"mangle", or more accurately, you can not read or alter the contents
of the https connection without compromising one or both hosts on the
connection.  An attacker would have to install a false certificate
authority in your browser, or have the cooperation with whatever site
you were accessing, or the issuer of its certificates.  Of course, not
possible means not possible within the next several thousand years
with all the energy of the known universe, assuming there isn't a
backdoor in all PKI, as opposed to not possible ever.

> Baring any serious bugs in your crypto implementation, the way to tell
> if you're talking securely to the site you intend is to examine the
> certificate used to encrypt the traffic.  If the certificate (and hence
> the public key) are trusted, it should not be possible for anyone to
> listen-in on your communication, regardless of whether or not they have
> access to the traffic (assuming, of course, that you trust public-key
> encryption).

Examining the certificate used to encrypt the traffic does not assure
you are talking 'securely'.  What is 'securely?  Examining the
certificate tells you what entity you're connecting to, according to
who.  The certificate itself is only as trustable as its issuing
certificate authority.  The issuing certificate authority is usually
one of the big vendors.  Verisign being my example.  There are many
others.  When you downloaded you browser, it came with a set of
certificate authorities.  Any root certificate installed after that
could be used to certify authenticity of an attacker's forged SSL
certificates.  The Tor people have identified ISPs that do this in
foreign countries.  They give their users 'software' to install to
'get internets'.  That software installs the ISP's root cert, and the
ISP can then play verisign on your secure connections.  Unless this
has happened, you are as secure as anyone in America, at leas as far
as https is concerned.

> So...make sure the certificate for the far-end was issued to your bank
> and not to some local Nepal company.   And pay close attention to any
> pop-ups your browser throws about certificates.

Who issued the certificate according to the certificate is not that
relevant, as a malicious certificate authority can easily say their
Verisign.  When a bad guy installs a rogue root cert on your system,
he doesn't have to call his certificate authority Evil Inc.  What is
important is if he can be confident that his computer has not been
tampered with to install a bogus root certificate.  dmcrypt/LUKS helps
with that.