SSL Man-in-the-middle

Has anyone given much thought to the feasability of a man-in-the-middle
attack against an SSL (or other similar) transaction?  To me, the
possibility seems obvious, so I figure it must have been discussed before,
though I haven't seen it.

The basic idea is pretty simple, really a flaw in the user interface of the
browser more than a flaw in SSL.  Neither browsers nor servers routinely
validate that they are communicating with the entity they think they are.
 Sure, with netscape you can ask for the document information window, which
shows the server's public key information, but this isn't a common action
among users, and certainly isn't something you'd want to do for every page
you viewed.

The only readily accessible information about security is that blue key at
the bottom of the netscape window.  Netscape docs tell you that if that key
is blue, your transaction is "secure."  In reality, the only thing that key
means is that you've negotiated a session key and are encrypting your
communications.  It says nothing about the fact that you're actually
communicating with the correct party.  Authentication is a large part of
security, and Netscape doesn't make that information conveniently
available.

Consider the following example.  Bob wants to communicate securely with
Alice.  He fires up his "secure" browser, looks up Alice's address in the
DNS and makes a connection.  He then sends Alice a document and
disconnects.

Now consider the following attack on the scenario:  Bob still wants to
 communicate with Alice.  He fires up his browser and looks up Alice in the
DNS.  Mallet, who wants the information Bob's sending, has subverted
Alice's DNS server and replaced Alice's IP address with his own, making a
note of the proper value.  Thus, when Bob looks up Alice's address in DNS,
he gets the wrong information and contacts Mallet instead.  Mallet performs
the SSL protocol with Bob, pretending to be the server, and then with
Alice, pretending to be the client.

Since neither the browser nor the server perform any authentication checks,
neither Bob nor Alice know they are really speaking to Mallet.  The best
Alice can do is check the IP address of the client she's speaking to, but
if Mallet has his own DNS, he can make the IP address map to whatever name
he wants, including Bob, in order to fool alice.  Even if Alice doesn't
depend on the DNS for IP resolution, probably doesn't know that the IP
address in question is really Mallet's, since it looks just like any other
IP address to her.

In this scenario, Bob gets a warm fuzzy since his key is blue and he knows
his information is being encrypted as it goes out.  Alice has a smaller
fuzzy, since she believes the transaction is secure from prying eyes.
 Mallet has a *really big* fuzzy, since he's able to read the data Bob
sends, decrypt it, save it, then re-send it to Alice.

I've read through the SSL spec, and it provides authentication for both the
server and the client, but these features are rarely used, probably because
they are somewhat inconvenient for the user.  A good first step would be to
include the IP address of the server in the certificate signed by VeriSign.
 In this way, browsers could perform automatic checks that the IP address
in the certificate is actually the one that's being communicated with.
 This does raise other questions (such as protecting from IP spoofing), but
IMHO would be a good way of providing an automatic "first check" without
inconveniencing users.  The added inconvenience of obtaining a new
certificate when your server's IP address changes is fairly minor, and
could be viewed as necessary overhead for doing secure transactions via the
Net.



--
==========================================================================
David J. Bianco			| Web Wonders, Online Oddities, Cool Stuff
iTribe, Inc.			| Phone: (804) 446-9060 Fax: (804) 446-9061
Suite 1700, World Trade Center	| email: <bianco@itribe.net>
Norfolk, VA 23510		| URL  : http://www.itribe.net/~bianco/

On Sep 22, 10:10, David J. Bianco sent the following to the NSA's mail
archives:
> Subject: SSL Man-in-the-middle
|| I've read through the SSL spec, and it provides authentication for both
|| the server and the client, but these features are rarely used, probably
|| because they are somewhat inconvenient for the user.  A good first step
|| would be to include the IP address of the server in the certificate
|| signed by VeriSign. In this way, browsers could perform automatic checks
|| that the IP address in the certificate is actually the one that's being
|| communicated with. This does raise other questions (such as protecting
|| from IP spoofing), but IMHO would be a good way of providing an
automatic
||  "first check" without inconveniencing users.  The added inconvenience
of
|| obtaining a new certificate when your server's IP address changes is
|| fairly minor, and could be viewed as necessary overhead for doing secure
|| transactions via the Net.
||
||

Of course, the above is complete and utter crap (as Simon Spero pointed out
to me in much, much more polite terms 8-).  Let me take a stab at v2.0:

I've read through the SSL spec, and it provides authentication for both the
server and the client, though these features are rarely used, probably
because they are somewhat inconvenient for the user.  A good practice would
be to always code your SSL app to check that the CN (Common Name) field of
the certificate is the same as the hostname listed in the URL (CN always
appears to be an IP address, at least for Netscape server certificates).


Still, even with the bogus last paragraph, I stand by the rest of my post.
 I obviously haven't seen Netscape source, so I don't really know what
checks it might have, but none of the other SSL apps I've seen have an
auto-check feature, though it doesn't seem to be much more trouble at all.


--
==========================================================================
David J. Bianco			| Web Wonders, Online Oddities, Cool Stuff
iTribe, Inc.			| Phone: (804) 446-9060 Fax: (804) 446-9061
Suite 1700, World Trade Center	| email: <bianco@itribe.net>
Norfolk, VA 23510		| URL  : http://www.itribe.net/~bianco/

On Fri, 22 Sep 1995, David J. Bianco wrote:
> Has anyone given much thought to the feasability of a man-in-the-middle
> attack against an SSL (or other similar) transaction?  To me, the
> possibility seems obvious, so I figure it must have been discussed before,
> though I haven't seen it.
....
> Since neither the browser nor the server perform any authentication checks,
> neither Bob nor Alice know they are really speaking to Mallet.  The best
> Alice can do is check the IP address of the client she's speaking to, but

Ah, err, the infamious problem of Netscape Navigator refusing to talk to 
SSL httpd's because they don't have a certificate issued by Verisign is 
caused by the client authentication the Server certificate.
To get a Verisign signed x509 certificate requires quite a bit of proof 
that your company is who they claim they are.  So server authentication 
is used.

eric
--
Eric Young                  | Signature removed since it was generating
AARNet: eay@mincom.oz.au    | more followups than the message contents :-)

On Sep 25,  9:35, Eric Young sent the following to the NSA's mail archives:
> Subject: Re: SSL Man-in-the-middle
||
|| On Fri, 22 Sep 1995, David J. Bianco wrote:
|| > Has anyone given much thought to the feasability of a
man-in-the-middle
|| > attack against an SSL (or other similar) transaction?  To me, the
|| > possibility seems obvious, so I figure it must have been discussed
before,
|| > though I haven't seen it.
|| ....
|| > Since neither the browser nor the server perform any authentication
checks,
|| > neither Bob nor Alice know they are really speaking to Mallet.  The
best
|| > Alice can do is check the IP address of the client she's speaking to,
but
||
|| Ah, err, the infamious problem of Netscape Navigator refusing to talk to
|| SSL httpd's because they don't have a certificate issued by Verisign is
|| caused by the client authentication the Server certificate.
|| To get a Verisign signed x509 certificate requires quite a bit of proof
|| that your company is who they claim they are.  So server authentication
|| is used.
||

Not so.  VeriSign can only vouch for identity, not intention.  I can fork
out $300 (at last count) and get a signed certificate for my fake company.
 If the stakes are high enough, I can incorporate fairly cheaply, get a
business license, and then I'd have a real company I could submit as.

Or, if I'm lazy, don't have enough money, or unwilling to leave a paper
trail, I'd break into someone's weakly secured server and steal their
certificate.

In either case, I've obtained a "legitimate" signed certificate for
illegitimate purposes.  That's why I don't think just verifying the
signature on the certificate is nearly enough.

--
==========================================================================
David J. Bianco			| Web Wonders, Online Oddities, Cool Stuff
iTribe, Inc.			| Phone: (804) 446-9060 Fax: (804) 446-9061
Suite 1700, World Trade Center	| email: <bianco@itribe.net>
Norfolk, VA 23510		| URL  : http://www.itribe.net/~bianco/

I can confirm that, at least up to 1.2, netscape navigator does not do any 
validation beyond checking the signer of the certificate. 

Exactly - the trust model used in Navigator 1.1N requires you to trust 
every single owner of a valid certificate. Getting hold of any key is 
vastly easier than having to obtain a specific key; in the worst case, 
you just buy your own - SSL exchanges are repudiable, and a few simple 
tricks can make sure you cerificiate doesn't show up in the "Document 
Information" dialog box. Or, since there are is CRLing, accidentaly lose 
you private key, notify verisni and get a revocation. 

To detect the attack without using either a modified client, or a nice
proxy that checks for you, you must do packet-tracing on all SSL
connections, regenerate the exchange, and then review each exchange to
look for suspicious certificates.

Simon Spero writes:

> Exactly - the trust model used in Navigator 1.1N requires you to trust 
> every single owner of a valid certificate. Getting hold of any key is 
> vastly easier than having to obtain a specific key; in the worst case, 
> you just buy your own - SSL exchanges are repudiable, and a few simple 
> tricks can make sure you cerificiate doesn't show up in the "Document 
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Information" dialog box.

I'd appreciate some documentation for this, please.  How can you make
this happen?


-- Jeff

In article <Pine.SOL.3.91.950925124443.359B-100000@chivalry>, ses@tipper.oit.unc.edu (Simon Spero) writes:
> Exactly - the trust model used in Navigator 1.1N requires you to trust 
> every single owner of a valid certificate. Getting hold of any key is 
> vastly easier than having to obtain a specific key; in the worst case, 
> you just buy your own - SSL exchanges are repudiable, and a few simple 
> tricks can make sure you cerificiate doesn't show up in the "Document 
> Information" dialog box.

  Can you explain to me how you would get the Navigator to accept your
certificate, but not display anything in the "Document Information"
dialog?

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Jeff - there are two ways to get the document information right (or wrong).

The first approach is to use redirects to point the client back at the 
original server once you've grabbed whatever info you want for the 
request. Redirects from https -> https don't trigger a warning box. You 
may need to rewrite the URL slightly to prevent loop detection (stick a . 
at the end of the hostname, or add a port, etc. 

The second approach is to only intercept requests for inline images. 
These don't affect the document information window, and give you full 
access to the whole request, which may have user authentication information 
associated with it, in the URL or in  header fields. Image requess can be 
identified reliably through simple traffic analysis.

Simon

Contract with America - Explained!			|Phone: +44-81-500-3000
Contract: verb						|Mail: ses@unc.edu
1) To shrink or reduce in size - the economy contracted +-----------------------
2) To become infected -My baby contracted pneumonia when they stopped my welfare