Re: going around the crypto
This isn't really a problem with the servers though, the problem lies in the fact that client-side certs are (effectively) unworkable. I know of a number of organisations who wanted to use them and ran into so many problems just with pilots involving small numbers of (presumably) experienced users that they gave up on trying to deploy them to the masses. If we had an all- encompassing PKI (ie.if cert management was easy) and if we could assume technically clueful users and if those users really cared about security (rather than seeing it as an impediment to getting their work done, which it often is), then client-side certs would be feasible. At the moment they're just not workable except within closed communities where you can control a lot of the parameters (you run the PKI, you vet the users, and you tell them you won't talk to them unless they take the appropriate security precautions and hope you don't have competitors who'll let them in without this). It is my understanding that MIT has a number of widely-used web applications (eg student registration) that have been using only client certs for authentication for a couple of years with reasonable success. You might say that this makes your point (these are MIT people, after all, hence closed, vetted, clueful, etc), but it is reasonably large-scale (~20K users or so, I think). The point, perhaps, is that this PKI deployment duplicates, more or less, for the web the functionality that Kerberos provided ten years ago for its suite of applications (telnet etc). So it's comforting to know that a PKI can do that much. *8^)* - RL "Bob"
Re: going around the crypto
"Steven M. Bellovin" wrote: It's clearly not automatic, but I suspect it would work User behaviour is the weak point here--while the browsers WILL notify you that the cert is signed by a CA you don't recognize, they also give you the option of accepting the cert, which most users will just blindly accept. Netscape gives you a couple of options here--accept the site cert for this session only, or accept it forever; I expect lots of users will choose "forever", since that's simpler. -- -- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Networks [EMAIL PROTECTED] -Expressed opinions are my own, not my employer's--
Re: going around the crypto
Michael Helm wrote: The attacker could also present a certficate from a fake CA with an appropriate name -- say, "Netscape Security Services", or something that Right. In which case Netscape brings up a different dialog which says that the server certificate is signed by an unrecognized CA. Again, you can proceed, but it's not like it's automatic. It's clearly not automatic, but I suspect it would work In many organizations which have attempted to do pki, it is often the case that a home-made certificate authority with a self-signed root CA certificate is created that issues in-house certificates for servers, clients, or whatever. But many of those orgs. have found distributing the root CA certificate very problematical, with the result that these acceptance dialogs alluded to above becomes routine to the user community. The first time this happens you probably look at what the many pop up windows are saying, puzzle over them, even dial up the local help desk. The tenth time you just hold down the mouse button whip thru it. It's simply amazing how much disinformation there is floating around about this stuff. If the organization attempting to do PKI isn't incompetent, they burn their cert into the install package for the browser that they give to users, eliminating this problem altogether. Sorry if I'm starting to sound a bit strident. I know that Netscape's PKI isn't anywhere within sight of perfect, but it's better than a lot of people give it credit for. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: going around the crypto
- Original Message - From: Peter Gutmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 14, 1999 6:03 AM Subject: Re: going around the crypto [...] Smart cards with thumbprint readers are one step in this direction, although they're currently prohibitively expensive. Siemens is experimenting with such a device in mobile phones, so it can't cost that much: http://www.siemens.com.hk/press/icp01.htm Enzo
Re: going around the crypto
It's my understanding that in order to exploit this, you'd have to essentially
set yourself up as a proxy after sending the RDP advert If this is the case,
wouldn't the fact that the man in the middle did not have the cert that
corresponded to the domain name cause at least one warning for most
browsers? ('certificate name check' in netscape, 'wrong certificate name' in
Opera). Otherwise, you'd just be acting as a router and SSL would prevent
sniffing. Am I missing something?
-Mike
"Steven M. Bellovin" [EMAIL PROTECTED] 08/13 9:16 AM
The L0pht has issued a new advisory for an routing-type attack that can,
they say, allow for man-in-the-middle attacks against SSL-protected sessions
(http://www.l0pht.com/advisories/rdp.txt).
The implication -- that there's a flaw in SSL -- is probably wrong. But
they're dead-on right that there's a real risk of man-in-the-middle attacks,
because the attacker can go around the crypto.
By sending the proper ICMP packets to a vulnerable host (most Windows 95/98
boxes, and some Solaris/SunOS systems), outbound traffic can be routed to an
attacker's machine. This machine can pretend to be the destination of
the SSL-protected call; it in turn calls the real destination.
The obvious protection is for users to check the certificate. Most users, of
course, don't even know what a certificate is, let alone what the grounds are
for accepting one. It would also help if servers used client-side
certificates for authentication, since the man-in-the-middle can't spoof
the user's certificate. But almost no servers do that.
This is why I wrote, a year ago, that we effectively have no PKI for the Web.
It also underscores the importance of looking at the entire system design,
rather than just the crypto. Crypto alone can't save the world; it's
necessary, but far from sufficient.
Re: going around the crypto
In message [EMAIL PROTECTED], "MIKE SHAW" writes:
It's my understanding that in order to exploit this, you'd have to essentiall
y
set yourself up as a proxy after sending the RDP advert If this is the case,
wouldn't the fact that the man in the middle did not have the cert that
corresponded to the domain name cause at least one warning for most
browsers? ('certificate name check' in netscape, 'wrong certificate name' in
Opera). Otherwise, you'd just be acting as a router and SSL would prevent
sniffing. Am I missing something?
Not as a proxy, since that's a different protocol from the host, but as the
end-system. Yes, you have to issue yourself a fake certificate, but I suspect
that that's not an insurmountable problem. And of course, that certificate is
signed by someone you've invented with a plausible name -- probably something
corresponding to the name of the site you're impersonating. Say, "Amazon.com
Electronic Security Services" or some such.
Re: going around the crypto
"Steven M. Bellovin" [EMAIL PROTECTED] writes: The L0pht has issued a new advisory for an routing-type attack that can, they say, allow for man-in-the-middle attacks against SSL-protected sessions (http://www.l0pht.com/advisories/rdp.txt). The implication -- that there's a flaw in SSL -- is probably wrong. But they're dead-on right that there's a real risk of man-in-the-middle attacks, because the attacker can go around the crypto. By sending the proper ICMP packets to a vulnerable host (most Windows 95/98 boxes, and some Solaris/SunOS systems), outbound traffic can be routed to an attacker's machine. This machine can pretend to be the destination of the SSL-protected call; it in turn calls the real destination. The obvious protection is for users to check the certificate. Most users, of course, don't even know what a certificate is, let alone what the grounds are for accepting one. It would also help if servers used client-side certificates for authentication, since the man-in-the-middle can't spoof the user's certificate. But almost no servers do that. This is why I wrote, a year ago, that we effectively have no PKI for the Web. It also underscores the importance of looking at the entire system design, rather than just the crypto. Crypto alone can't save the world; it's necessary, but far from sufficient. For this to work requires more than the users to not check the certificate. It requires them to deliberately ignore a warning from the browser. To whit, if you attempt to connect to a site where the domain name you enter in the URL does not match the certificate (i.e. the Common Name), then Netscape brings up a dialog like: The certificate that the site 'foo.bar.com' has presented does not contain the correct site name. It is possible, though unlikely, that someone may be trying to intercept your communication with this site. If you suspect the certificate shown below does not belong to the site you are connecting with, please cancel the connection and notify the site administrator. Now, I wish this were phrased more strongly, but I think it makes the point fairly clearly. At one point, IE wouldn't even give you the option of continuing the connection. I'm not sure what it does now. Now, this does require that the CAs that your browser trusts follow the Common Name=domain name convention, but that's just a special case of trusting your CAs. Incidentally, the current HTTP/TLS draft (draft-ietf-tls-https-02.txt) requires that the browser check the cert against the domain name but provides a slightly more complicated check favoring subjectAltName over CN. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/
Re: going around the crypto
"Steven M. Bellovin" [EMAIL PROTECTED] writes: Now, this does require that the CAs that your browser trusts follow the Common Name=domain name convention, but that's just a special case of trusting your CAs. The attacker could also present a certficate from a fake CA with an appropriate name -- say, "Netscape Security Services", or something that plays on the site name they're trying to impersonate -- "Amazon.Com Encryption Certification Center" if someone is trying to reach Amazon.com or some such. Right. In which case Netscape brings up a different dialog which says that the server certificate is signed by an unrecognized CA. Again, you can proceed, but it's not like it's automatic. I'm fairly sure that IE refuses to connect at all. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/
Re: going around the crypto
Right. But to do that you would most have to install your homemade CA root cert on their browser, which would probably tip off most users (at least a few customer would call clueless as to how to install a CA--I know ours would). The only CAs with commonly accepted root certs wouldn't let you get one from them without checking your credentials first. So it looks like unless you compromised the target server first and somehow stole their SSL certificate, you'd have to create your own that matched the domain name and that would make the exploit very untransparent to the exploited user. Unless of course, there is an easy way to make commonly accepted certificates without authentication--which would be a fatal flaw in the whole protocol. Don't get me wrong, I'm not downplaying the significance of the L0pht's advisory at all. I'm just trying to get a grasp on the implications. -Mike Not as a proxy, since that's a different protocol from the host, but as the end-system. Yes, you have to issue yourself a fake certificate, but I suspect that that's not an insurmountable problem. And of course, that certificate is signed by someone you've invented with a plausible name -- probably something corresponding to the name of the site you're impersonating. Say, "Amazon.com Electronic Security Services" or some such.
Re: going around the crypto
In message [EMAIL PROTECTED], EKR writes: "Steven M. Bellovin" [EMAIL PROTECTED] writes: Now, this does require that the CAs that your browser trusts follow the Common Name=domain name convention, but that's just a special case of trusting your CAs. The attacker could also present a certficate from a fake CA with an appropriate name -- say, "Netscape Security Services", or something that plays on the site name they're trying to impersonate -- "Amazon.Com Encrypt ion Certification Center" if someone is trying to reach Amazon.com or some such . Right. In which case Netscape brings up a different dialog which says that the server certificate is signed by an unrecognized CA. Again, you can proceed, but it's not like it's automatic. It's clearly not automatic, but I suspect it would work
RE: going around the crypto
I haven't looked at the l0pht page yet, but you should be aware that the browser checks the certificate so the user doesn't have to, under most circumstances. The browser will display an alert if the hostname in the URL doesn't matche the commonName in the certificate or if the certificate is not issued by a trusted CA. Thus, unless the man-in-the-middle can produce such a certificate, which will require fooling a CA into giving him one, the client will not quietly negotiate with him, believing they're talking to the end server. If he can get such a certificate, that's an attack against the PKI, not the protocol. Two significant dangers with SSL as deployed today: 1) The certificate is checked against the URL, so the security mechanism is built upon the URL reflecting the user's intent. If the user doesn't display the URL, doesn't check it, or is fooled by a plausible yet incorrect URL, they will not be protected by the protocol or the PKI. (Note that this would require the user to be directed to the bad URL, although that could probably be done by modifying insecure web pages with links to secure ones.) 2) Most browsers extant do not check CRLs and most certificates don't have CRL distribution point extensions, so certificates cannot, in practice, be revoked. Tim Dierks VP of Engineering, Certicom [EMAIL PROTECTED] 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steven M. Bellovin Sent: Friday, August 13, 1999 7:17 AM To: [EMAIL PROTECTED] Subject: going around the crypto The L0pht has issued a new advisory for an routing-type attack that can, they say, allow for man-in-the-middle attacks against SSL-protected sessions (http://www.l0pht.com/advisories/rdp.txt). The implication -- that there's a flaw in SSL -- is probably wrong. But they're dead-on right that there's a real risk of man-in-the-middle attacks, because the attacker can go around the crypto. By sending the proper ICMP packets to a vulnerable host (most Windows 95/98 boxes, and some Solaris/SunOS systems), outbound traffic can be routed to an attacker's machine. This machine can pretend to be the destination of the SSL-protected call; it in turn calls the real destination. The obvious protection is for users to check the certificate. Most users, of course, don't even know what a certificate is, let alone what the grounds are for accepting one. It would also help if servers used client-side certificates for authentication, since the man-in-the-middle can't spoof the user's certificate. But almost no servers do that. This is why I wrote, a year ago, that we effectively have no PKI for the Web. It also underscores the importance of looking at the entire system design, rather than just the crypto. Crypto alone can't save the world; it's necessary, but far from sufficient.
Re: going around the crypto
"Steven M. Bellovin" [EMAIL PROTECTED] writes: The obvious protection is for users to check the certificate. Most users, of course, don't even know what a certificate is, let alone what the grounds are for accepting one. It would also help if servers used client-side certificates for authentication, since the man-in-the-middle can't spoof the user's certificate. But almost no servers do that. This isn't really a problem with the servers though, the problem lies in the fact that client-side certs are (effectively) unworkable. I know of a number of organisations who wanted to use them and ran into so many problems just with pilots involving small numbers of (presumably) experienced users that they gave up on trying to deploy them to the masses. If we had an all- encompassing PKI (ie.if cert management was easy) and if we could assume technically clueful users and if those users really cared about security (rather than seeing it as an impediment to getting their work done, which it often is), then client-side certs would be feasible. At the moment they're just not workable except within closed communities where you can control a lot of the parameters (you run the PKI, you vet the users, and you tell them you won't talk to them unless they take the appropriate security precautions and hope you don't have competitors who'll let them in without this). The ideal interface for this sort of thing would be a magic box (which could be shaped like a smart card, but could be something else) with pre-generated certificates which the user can't delete, mangle, or lose (a number of European countries are aready going down this path), with a "Press button to authenticate yourself" sign which lights up when client-side authentication is needed. Smart cards with thumbprint readers are one step in this direction, although they're currently prohibitively expensive. Peter.
Re: going around the crypto
"Steven M. Bellovin" wrote: The obvious protection is for users to check the certificate. Most users, of course, don't even know what a certificate is, let alone what the grounds are for accepting one. It would also help if servers used client-side certificates for authentication, since the man-in-the-middle can't spoof the user's certificate. But almost no servers do that. The user doesn't need to check the certificate. Certificates for HTTP servers contain the host name of the machine they certify. The web browser checks the hostname in the certificate against the hostname in the URL. All the user must do is check the hostname in the URL that is displayed on his screen. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: going around the crypto
The attacker could also present a certficate from a fake CA with an appropriate name -- say, "Netscape Security Services", or something that Right. In which case Netscape brings up a different dialog which says that the server certificate is signed by an unrecognized CA. Again, you can proceed, but it's not like it's automatic. It's clearly not automatic, but I suspect it would work In many organizations which have attempted to do pki, it is often the case that a home-made certificate authority with a self-signed root CA certificate is created that issues in-house certificates for servers, clients, or whatever. But many of those orgs. have found distributing the root CA certificate very problematical, with the result that these acceptance dialogs alluded to above becomes routine to the user community. The first time this happens you probably look at what the many pop up windows are saying, puzzle over them, even dial up the local help desk. The tenth time you just hold down the mouse button whip thru it.
