Re: SSL & Man In the Middle Attack

From: Anne & Lynn Wheeler (lynn@garlic.com)
Date: 01/13/03 

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Mon, 13 Jan 2003 11:48:16 GMT

"NEWS.DFN.CIS" <anyone@nowhere.com> writes:
> Hi, I'm a newbie
>
> I was wondering if SSL was still vulnerable to man in the middle attack?
>
> E.g., if some one is sitting between me and an trusted server, and
> intercepts our handshake during initiation of our secure conversation, isn't
> it possible for the middle man to intercept all messages from server to me
> (but not from me to server)?

server sends client a signed message along with a digital certificate.
the client validates the digital certificate (i.e. it is for the
server that i think i'm talking to) and then validates the signed
message using the public key in the digital certificate (i.e. the
server has to be the one described in the digital certificate or
otherwise the signed message wouldn't verify).

client generates a random secret key, encrypts it with the server's
public key (from the certificate) and sends it to the server. from
then on the server and client encrypt everything using the generated
random secret key. only the server specified in the validated digital
certificate will be able to decrypt the random secret key (since they
should be the only one with the private key capable of decrypting
something that had been encrypted with the corresponding public key).
the client knows the random secret key because it generated it ... the
server knows the random secret key because it was able to decrypt it
with the server's private key.
recent refs:
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#41 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003.html#42 basic pki question

there used to be an issue that a man-in-the-middle could play during
SSL setup negotiation ... where it would fake messages as to the
aggreed upon secret key encryption protocol ... and force both the
client & server to select the weakest encryption protocol (with the
shortest key length). then once the secret key was exchanged ... the
man-in-the-middle was out of the loop ... other than attacking the
encrypted messages to determine the secret key (which it had forced to
the shortest possible).

other attacks on SSL infrastructure ... as opposed to SSL protocol ...
is to get the client redirected to a different site by substituting a
different URL. The actual SSL check is does the URL in the certificate
match the URL that the client entered. If the attack can get the
client to enter the URL of the man-in-the-middle (i.e. a bogus URL)
... who has a valid certificate for their site ... then the SSL
protocol works to the man-in-the-middle ... who then can fakes a
client to the real web site.

basically the SSL certificate protocol was to handle an ip-address
take-over in the domain name infrastructure ... aka man-in-the-middle
corrupted a DNS cache entry for a URL->IP-address mapping with the
wrong ip-address. The client typed in the correct URL ... but was sent
off to the wrong ip-address. The server at the fraudulent website
would be unable to establish a correct certificate for the original
URL.

However, if the attack involved getting the client's browser somehow
to go to the wrong URL ... then the fraudulent website could have a
valid certificate for the fraudulent URL and everything proceeds.
Since frequently a client is just clicking on something ... rather
than actually typing in the actual URL ... there could be lots of
opportunities for incorrect URLs (even to trying to obtain domain
names for the common mistypings of URLs).

the other is trying to spoof getting an issued certificate for the
desired URL (a recent case was an IE problem that accepted as valid,
certificates generated by individuals).

misc refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts 

-- 
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/ 
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm

Relevant Pages

  • Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle
    ... SSL only validates you are talking to a SSL certified server; ... They can simply edit the URL the client program ... can be done by using a X.509 certificate on both ends, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: LDP client authentication fails
    ... I got the LDP working with LDAP server under server client authentication ... I did not installed the certificate in pfx format .. ... Client cert auth won't work without that. ...
    (microsoft.public.windows.server.active_directory)
  • Re: SSL & Man In the Middle Attack
    ... >> it possible for the middle man to intercept all messages from server to me ... > server sends client a signed message along with a digital certificate. ... > client generates a random secret key, ...
    (comp.security.misc)
  • Re: activesync issue
    ... On the SBS 2003 Server open the Server Management console. ... On the "Web Server Certificate" page, choose to create a new Web server ... Install the new certificate which created in above step on mobile device: ... Access to browse the Exchange Server 2003 client after you install ...
    (microsoft.public.windows.server.sbs)
  • [Full-disclosure] VMSA-2006-0010 - SSL sessions not authenticated by VC Clients
    ... X.509 certificate when creating an SSL session, ... Both the client and server need certificates from a mutually-trusted ... VirtualCenter 2.0.1 Patch 1 and VirtualCenter 1.4.1 Patch ...
    (Full-Disclosure)