Re: Cracking SSL
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 10/12/03
- Next message: kurt wismer: "Re: Controversial paper - Good response article on ZDNet"
- Previous message: David A. Scott: "Re: AES optimizations for different implemenations"
- In reply to: Roger Schlafly: "Re: Cracking SSL"
- Next in thread: Mack: "Re: Cracking SSL"
- Reply: Mack: "Re: Cracking SSL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 12 Oct 2003 13:57:56 GMT
"Roger Schlafly" <rogersc@mindspring.com> writes:
> Possibly secure, depending on how it is used. As SSL is commonly
> used, there are various attacks possible. Eg, most people do not
> use client certs, so a man-in-the-middle attack is possible.
SSL was originally designed to address the situation is the server
that I think I'm talking to ... really the server that I'm talking to
... basically countermeasure for some sort of dns and/or ip-address
routing exploit.
basically, the browser has a table of public keys that are trusted by
the client to validate public key certificates for servers. the
servers basically contain a domain name and a public key.
typically a client browser 1) contacts a server, 2) gets back a server
domain name certificate, 3) the browser validates the integrity of the
server certificate with the public key from the internal browswer
table of trusted public keys and 4) compares the certificate domain
name with the domain name in the URL used to contact the server.
client certificates didn't come along until later. I believe that we
introduced the requirement for client certificates and mutual
authentication before SSL3. This was for the original payment gateway
and we wanted not only that the webserver validated the payment
gateway server (i.e. in the payment transaction with the payment
gateway, the payment gateway has the ssl role of the "server" ... not
the webserver) ... and the payment gateway server validate the
webserver (the webserver is the client of the payment gateway server).
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
the rise of aads
http://www.garlic.com/~lynn/index.html#aads
was in large part having to do end-to-end due diligence on all
business processes related to the original SSL, the uses of SSL, PKIs,
certification authorities, etc and realizing that in (nearly) all (at
least online) cases .... the certificates were redundant and
superfluous duplication of other business operations.
SSL3 with "mutual" authentication (client and server) came along after
the payment gateway stuff and the requirement for "client"
certificates as part of the operation.
Note that the original idea was that SSL would be used for all of the
shopping experience .... from the initial contact of the merchant
website, thru all of the shopping experience, all the way thru
checkount and providing the credit card number.
The problem was that the SSL overhead caused a five-fold decrease in
the server shopping capacity ... so eventually SSL was eventually
restricted to just the credit card phase for possibly something like
99.99 percent of the SSL uses around the world today.
So from the standpoint of "commonly used" .... the user may typically
provide the initial, non-ssl URL for the shopping experience ... but
when it comes to the most widely use of SSL ... the user clicks on a
button at the shopping website to enter the SSL environment ... and
most users pay little or no attention to the URL that the button
serves up. A comon exploit is to be at a bogus shopping site (with no
SSL) ... and then have a user hit the checkout button to enter the SSL
sesssion. The URL that the checkpoint at the bogus shopping site
caughs up turns out to be identical to the domain name of the bogus
shopping site ... and of course the SSL validation proves that the
domain name in the (bogus) URL, in fact matches the domain name in the
supplied certificate.
The issue, of course, is that the breadth of MITM protection specified
by the technical SSL description ... is significantly less than the
breadth of MITM exploits available to people wanting to do fraud. In
some ways, it is like saying that SSL specifies the security of the
bank vault door ... but washes its hands of any issue regarding bank
vault doors being placed in empty fields .... it isn't their fault
that the crooks can walk around the door since there are no walls,
floors, ceilings, etc.
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
- Next message: kurt wismer: "Re: Controversial paper - Good response article on ZDNet"
- Previous message: David A. Scott: "Re: AES optimizations for different implemenations"
- In reply to: Roger Schlafly: "Re: Cracking SSL"
- Next in thread: Mack: "Re: Cracking SSL"
- Reply: Mack: "Re: Cracking SSL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
