What happened with the session fixation bug?
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG vPV62zjEtpTJHTV5lKXu2Sw+/5fke2gh9AwPeqQj 4oqqXlvYYKn9rR63ZsSEEjgV5fVyWT9+e6YttP3G/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
James A. Donald wrote:
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed?
Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation: a) If a session ID arrives, it should already exist in the database. b) Session IDs include HMACs. Session fixation is defeated by either of these. Modulo insider attacks, of course. :-) -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
-- James A. Donald:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed?
On 20 May 2005 at 23:21, Ben Laurie wrote:
Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation:
a) If a session ID arrives, it should already exist in the database.
b) Session IDs include HMACs.
The way to beat session fixation is to issue a privileged and impossible to predict session ID in response to a correct login. If, however, you grant privileges to a session ID on the basis of a successful login, which is in fact the usual practice, you are hosed. The normal programming model creates a session ID, then sets variables and flags associated with that session ID in response to forms submitted by the user. To prevent session fixation, you must create the session ID with unchangeable privileges from the moment of creation. Perhaps you do this, but very few web sites do. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG en30AWb8dk9T67RFzUse67CG7ZHHoOHC5OR/mndW 4T4xroZR7GeKinK0sMRNQ+4Pdj6ApUEu4FCGDghE5 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
James A. Donald wrote:
-- James A. Donald:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed?
On 20 May 2005 at 23:21, Ben Laurie wrote:
Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation:
a) If a session ID arrives, it should already exist in the database.
b) Session IDs include HMACs.
The way to beat session fixation is to issue a privileged and impossible to predict session ID in response to a correct login.
If, however, you grant privileges to a session ID on the basis of a successful login, which is in fact the usual practice, you are hosed. The normal programming model creates a session ID, then sets variables and flags associated with that session ID in response to forms submitted by the user. To prevent session fixation, you must create the session ID with unchangeable privileges from the moment of creation.
Why? I suspect you are thinking of an attack other than session fixation. How does your attack work? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
-- James A. Donald wrote:
The way to beat session fixation is to issue a privileged and impossible to predict session ID in response to a correct login.
If, however, you grant privileges to a session ID on the basis of a successful login, which is in fact the usual practice, you are hosed. The normal programming model creates a session ID, then sets variables and flags associated with that session ID in response to forms submitted by the user. To prevent session fixation, you must create the session ID with unchangeable privileges from the moment of creation.
Ben Laurie wrote:
How does your attack work?
Your business about MACS and stuff was to prevent the adversary guessing the users session ID. With "session fixation", the adversary does not try to guess the legitimate users session ID, instead he fools the browser of the legitimate user into using the adversary's session ID. Adversary accesses web site as if about to log in, gets a session ID. Then supplies false information to someone else's browser, causes that browser on some one else's computer to use that session ID. Someone else logs in with hacker's session ID, and now the adversary is logged in. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG fUQA7VMYJROi7AAUHD8ZmEHReDprBvrg3u3cL2VI 4NzEz9SAfaOzb7GhsAkM//vmMQKDsrdLEInHLumm3 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
James A. Donald wrote:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
all of them may have been less than expected ... the comoningly recognized SSL certificate issuers (that have their public key preloaded into common browsers) sell their certificates and have processes that look at whether you have a validly registered corporation. For most practical purposes this has been for e-commerce sites and the objective for the majority is protecting credit card numbers. however, the reported exploits .... and what seem to represent a significantly larger ROI (fraud for effort invested) is to harvest the merchant transaction file (containing all the accumulated transaction information that would have taken months of listening to gather) ... aka it is much easier to let the merchant gather and organize all the information on behalf of the crook. slightly related posting ... http://www.garlic.com/~lynn/2001h.html#61 Security proportional to risk the original ssl e-commerce work http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 had the user typing in the merchant webserver URL as a HTTPS session from the start and then it would check the domain name in the returned certificate (after all the digital signature gorp) with the domain name typed in. this is rarely if ever happening ... the common justification is running SSL during the shopping experience cuts the thruput by 80-90 percent. as a result, SSL is typically saved for the "check-out" button. so lets say you have been redirected to a fraudulent site and don't know it because the SSL domain name stuff hasn't been done yet. then comes time to do the check-out button. if it is a fraudulent site ... and since the crooks would then be supplying the URL with the check-out button ... the crooks are likely to have obtained a valid SSL certificate for some domain and that domain will match whatever the check-out button supplies. random past ssl certificate posts http://www.garlic.com/~lynn/subpubkey.html#sslcert crooks are capable of setting up valid dummy front companies ... it isn't a very large effort. most of what the CA TTPs do when they are verifying stuff ... is that the person applying for a certificate is in some way associated with a valid company that they claim to be associated with. then the CA TTPs check with the domain name infrastructure to see if the corporation that they just checked on ... is the same one listed as the owner of the subject domain name (modulo the issue that there can be a common company name, a DBA company name, and a legal company name ... all for the same corporation and all completely different names ... you sometimes will see this in credit card statements where the store-front name and the company name on the statement are different). As observed, one of the things SSL was for a countermeasure for integrity problems in the domain name infrastructure involving domain name hijacking (where the mapping of the domain name to an ip-address was altered to be a different ip-address, potentially fraudulent website). However, there have been more sophisticated domain name hijackings that have occured where both the domain name infrastructure records had both the name of the corporate owner as well as the ip-address altered. In this more sophisticated form, a crook with a perfectly valid dummy front corporation ... that has done the more sophisticated form of domain name hijacking ... could apply for a perfectly valid SSL domain name certificate ... and pass all the tests. in any case, that was my perception of what we were doing with SSL ten years ago. PKI is slightly different. One of the reasons that we coined the term "certificate manufactoring" was to try and differentiate what was comingly being referred to as PKI ... and what SSL domain name certificate stuff was actually doing. Note that there has been a proposal to somewhat address the more complex form of domain name hijacking (both the company name take-over as well as the ip-address take-over) ... which involves having domain name owners register a public key when they get a domain name. Then all future correspondance with the domain name infrastructure is digitally signed ... which then can be veriefied with the onfile public key. as a side note ... this is a non-PKI, certificateless implementation of public key. In any case, with authenticated correspondance ... there supposedly is less chance of domain name hijacking occuring. http://www.garlic.com/~lynn/subpubkey.html#certless This has somewhat been supported by the CA SSL domain name certification industry. The have a complex, expensive, and error-prone identification process to try to establish a valid corporation. And even then they are at the mercy of whether the company name listed in the domain name infrastructure is actually the correct company (i.e. their whole infrastructure otherwise is useless). The other advantage ... is that the Certification Authority can require that SSL domain name certificate applications also be digitally signed. Then the CA can turn an expensive, time-consuming, and error-prone identification process into a much simpler, cheaper, and reliable authentication process ... by retrieving the onfile public key from the domain name infrastructure for verifying the applicants digital signature (again note that this is a non-PKI, certificateless implementation that they would use as the trust basis for the whole SSL domain name certificate operation). There is some slight catch22 to this for the SSL domain name certificate business. First off, improving the integrity of the domain name infrastructure for the Certification Authority industry ... would also improve the integrity for everybody ... somewhat mitigating one of the original supposed requirements for having SSL domain name certificates in the first place. The other is that if the SSL certification industry found it viable to base their trust infrastructure on the certificateless, onfile public keys at the domain name infrastructure... it might be possible that the rest of the world might find them acceptable also. One could imagine a slightly modified SSL process where the public key didn't come from a certificate ... but was an onfile certificateless public key retrieved directly from the domain name infrastructure (in much the same way the CA industry has proposed doing). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
In message <427CCA9B.29132.760A1FC@localhost>, "James A. Donald" writes:
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
First, you mean "the Web PKI", not PKI in general. The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct. As for DNS hijacking -- that's what's behind "pharming" attacks. In other words, it's a real threat, too. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
In message <427CCA9B.29132.760A1FC@localhost>, "James A. Donald" writes:
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
First, you mean "the Web PKI", not PKI in general.
The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL.
I think you meant to write that James' reasoning is circular, but strangely, your reasoning is at least as unfounded - correlation not causality. And I think the evidence is pretty much against any causality, although this will be something that is hard to show, in the absence. * AFAICS, a non-trivial proportion of credit card traffic occurs over totally unprotected traffic, and that has never been sniffed as far as anyone has ever reported. (By this I mean lots of small merchants with MOTO accounts that don't bother to set up "proper" SSL servers.) * We know that from our experiences of the wireless 802.11 crypto - even though we've got repeated breaks and the FBI even demonstrating how to break it, and the majority of people don't even bother to turn on the crypto, there remains practically zero evidence that anyone is listening. FBI tells you how to do it: https://www.financialcryptography.com/mt/archives/000476.html As an alternate hypothesis, credit cards are not sniffed and never will be sniffed simply because that is not economic. If you can hack a database and lift 10,000++ credit card numbers, or simply buy the info from some insider, why would an attacker ever bother to try and sniff the wire to pick up one credit card number at a time? And if they did, why would we care? Better to let a stupid thief find a way to remove himself from a life of crime than to channel him into a really dangerous and expensive crime like phishing, box cracking, and purchasing identity info from insiders.
Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct.
But this is totally incorrect! The spyware installs on the users' machines, and thus does not need to sniff the wire. The assumption of SSL is (as written up in Eric's fine book) that the wire is insecure and the node is secure, and if the node is insecure then we are sunk. Eric's book and "1.2 The Internet Threat Model" http://iang.org/ssl/rescorla_1.html Presence of keyboard sniffing does not give us any evidence at all towards wire sniffing and only serves to further embarrass the SSL threat model.
As for DNS hijacking -- that's what's behind "pharming" attacks. In other words, it's a real threat, too.
Yes, that's being tried now too. This is I suspect the one area where the SSL model correctly predicted a minor threat. But from what I can tell, server-based DNS hijacking isn't that successful for the obvious reasons (attacking the ISP to get to the user is a higher risk strategy than makes sense in phishing). User node-based hijacking might be more successful. Again, that's on the node, so it can totally bypass any PKI based protections anyway. I say "minor threat" because you have to look at the big picture: attackers have figured out a way to breach the secure browsing model so well and so economically that they now have lots and lots of investment money, and are gradually working their way through the various lesser ways of attacking secure browsing. As perhaps further evidence of the black mark against so-called secure browsing, phishers still have not bothered to acquire control-of-domain certs for $30 and use them to spoof websites over SSL. Now, that's either evidence that $30 is too much to pay, or that users just ignore the certs and padlocks so it is no big deal anyway. Either way, a model that is bypassed so disparagingly without even a direct attack on the PKI is not exactly recommending itself. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
In message <200505311831.15142.iang@systemics.com>, Ian G writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
In message <427CCA9B.29132.760A1FC@localhost>, "James A. Donald" writes:
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
First, you mean "the Web PKI", not PKI in general.
The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL.
I think you meant to write that James' reasoning is circular, but strangely, your reasoning is at least as unfounded - correlation not causality. And I think the evidence is pretty much against any causality, although this will be something that is hard to show, in the absence.
Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement.
* AFAICS, a non-trivial proportion of credit card traffic occurs over totally unprotected traffic, and that has never been sniffed as far as anyone has ever reported. (By this I mean lots of small merchants with MOTO accounts that don't bother to set up "proper" SSL servers.)
Given what a small percentage of ecommerce goes to those sites, I don't think it's really noticeable.
* We know that from our experiences of the wireless 802.11 crypto - even though we've got repeated breaks and the FBI even demonstrating how to break it, and the majority of people don't even bother to turn on the crypto, there remains practically zero evidence that anyone is listening.
FBI tells you how to do it: https://www.financialcryptography.com/mt/archives/000476.
Sure -- but setting up WEP is a nuisance. SSL (mostly) just works. As for your assertion that no one is listening, I'm not sure what kind of evidence you'd seek. There's plenty of evidence that people abuse unprotected access points to gain connectivity.
As an alternate hypothesis, credit cards are not sniffed and never will be sniffed simply because that is not economic. If you can hack a database and lift 10,000++ credit card numbers, or simply buy the info from some insider, why would an attacker ever bother to try and sniff the wire to pick up one credit card number at a time?
Sure -- that's certainly the easy way to do it.
And if they did, why would we care? Better to let a stupid thief find a way to remove himself from a life of crime than to channel him into a really dangerous and expensive crime like phishing, box cracking, and purchasing identity info from insiders.
Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct.
But this is totally incorrect! The spyware installs on the users' machines, and thus does not need to sniff the wire. The assumption of SSL is (as written up in Eric's fine book) that the wire is insecure and the node is secure, and if the node is insecure then we are sunk.
I meant precisely what I said and I stand by my statement. I'm quite well aware of the difference between network sniffers and keystroke loggers.
Eric's book and "1.2 The Internet Threat Model" http://iang.org/ssl/rescorla_1.html
Presence of keyboard sniffing does not give us any evidence at all towards wire sniffing and only serves to further embarrass the SSL threat model.
As for DNS hijacking -- that's what's behind "pharming" attacks. In other words, it's a real threat, too.
Yes, that's being tried now too. This is I suspect the one area where the SSL model correctly predicted a minor threat. But from what I can tell, server-based DNS hijacking isn't that successful for the obvious reasons (attacking the ISP to get to the user is a higher risk strategy than makes sense in phishing).
They're using cache contamination attacks, among other things. ...
As perhaps further evidence of the black mark against so-called secure browsing, phishers still have not bothered to acquire control-of-domain certs for $30 and use them to spoof websites over SSL.
Now, that's either evidence that $30 is too much to pay, or that users just ignore the certs and padlocks so it is no big deal anyway. Either way, a model that is bypassed so disparagingly without even a direct attack on the PKI is not exactly recommending itself.
I agre completely that virtually no one checks certificates (or even knows what they are). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Steven M. Bellovin wrote:
Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement.
the major exploits have involved data-at-rest ... not data-in-flight. internet credit card sniffing can be easier than password sniffing .... but that doesn't mean that the fraud cost/benefit ratio is better than harvesting large transaction database files. you could possibly conjecture password sniffing enabling compromise/exploits of data-at-rest ... quick in&out and may have months worth of transaction information all nicely organized. to large extent SSL was used to show that internet/e-commerce wouldn't result in the theoritical sniffing making things worse (as opposed to addressing the major fraud vulnerability & treat). internet/e-commerce did increase the threats & vulnerabilities to the transaction database files (data-at-rest) ... which is were the major threat has been. There has been a proliferation of internet merchants with electronic transaction database files ... where there may be various kinds of internet access to the databases. Even when the prevalent risk to these files has been from insiders ... the possibility of outsider compromise can still obfuscate tracking down who is actually responsible. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Tuesday 31 May 2005 19:38, Steven M. Bellovin wrote:
In message <200505311831.15142.iang@systemics.com>, Ian G writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
In message <427CCA9B.29132.760A1FC@localhost>, "James A. Donald" writes:
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
First, you mean "the Web PKI", not PKI in general.
The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL.
I think you meant to write that James' reasoning is circular, but strangely, your reasoning is at least as unfounded - correlation not causality. And I think the evidence is pretty much against any causality, although this will be something that is hard to show, in the absence.
Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement.
Well, I'm not arguing it is technically hard. It's just un-economic. In the same sense that it is not technically difficult for us to get in a car and go run someone over; but we still don't do it. And we don't ban the roads nor insist on our butlers walking with a red flag in front of the car, either. Well, not any more. So I stand by my statement - correlation is not causality.
* AFAICS, a non-trivial proportion of credit card traffic occurs over totally unprotected traffic, and that has never been sniffed as far as anyone has ever reported. (By this I mean lots of small merchants with MOTO accounts that don't bother to set up "proper" SSL servers.)
Given what a small percentage of ecommerce goes to those sites, I don't think it's really noticeable.
Exactly my point. Sniffing isn't noticeable. Neither in the cases we know it could happen, nor in the areas. The one place where it has been noticed is with passwords and what we know from that experience is that even the slightest security works to overcome that threat. SSH is overkill, compared to the passwords mailouts that successfully protect online password sites.
* We know that from our experiences of the wireless 802.11 crypto - even though we've got repeated breaks and the FBI even demonstrating how to break it, and the majority of people don't even bother to turn on the crypto, there remains practically zero evidence that anyone is listening.
FBI tells you how to do it: https://www.financialcryptography.com/mt/archives/000476.
Sure -- but setting up WEP is a nuisance. SSL (mostly) just works.
SSH just works - and it worked directly against the threat you listed above (password sniffing). But it has no "PKI" to speak of, and this discussion is about whether PKI protects people, because it is PKI that is supposed to protect against spoofing - a.k.a. phishing. And it is PKI that makes SSL "just doesn't set up." Anyone who's ever had to set up an Apache web server for SSL has to have asked themselves the question ... "why doesn't this just work" ?
As for your assertion that no one is listening, I'm not sure what kind of evidence you'd seek. There's plenty of evidence that people abuse unprotected access points to gain connectivity.
Simply, evidence that people are listening. Sniffing by means of the wire. Evidence that people abuse to gain unprotected access is nothing to do with sniffing traffic to steal information. That's theft of access, which is a fairly minor issue, especially as it doesn't have any economic damages worth speaking of. In fact, many cases seem to be more accidental access where neighbours end up using each other's access points because the software doesn't know where the property lines are.
Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct.
But this is totally incorrect! The spyware installs on the users' machines, and thus does not need to sniff the wire. The assumption of SSL is (as written up in Eric's fine book) that the wire is insecure and the node is secure, and if the node is insecure then we are sunk.
I meant precisely what I said and I stand by my statement. I'm quite well aware of the difference between network sniffers and keystroke loggers.
OK, so maybe I am incorrectly reading this - are you saying that spyware is being delivered that incorporates wire sniffers? Sniffers that listen to the ethernet traffic? If that's the case, that is the first I've heard of it. What is it that these sniffers are listening for?
Eric's book and "1.2 The Internet Threat Model" http://iang.org/ssl/rescorla_1.html
Presence of keyboard sniffing does not give us any evidence at all towards wire sniffing and only serves to further embarrass the SSL threat model.
As for DNS hijacking -- that's what's behind "pharming" attacks. In other words, it's a real threat, too.
Yes, that's being tried now too. This is I suspect the one area where the SSL model correctly predicted a minor threat. But from what I can tell, server-based DNS hijacking isn't that successful for the obvious reasons (attacking the ISP to get to the user is a higher risk strategy than makes sense in phishing).
They're using cache contamination attacks, among other things.
...
As perhaps further evidence of the black mark against so-called secure browsing, phishers still have not bothered to acquire control-of-domain certs for $30 and use them to spoof websites over SSL.
Now, that's either evidence that $30 is too much to pay, or that users just ignore the certs and padlocks so it is no big deal anyway. Either way, a model that is bypassed so disparagingly without even a direct attack on the PKI is not exactly recommending itself.
I agre completely that virtually no one checks certificates (or even knows what they are).
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
Ahh-oops! That particular reply was scrappily written late at night and wasn't meant to be sent! Apologies belatedly, I'd since actually come to the conclusion that Steve's statement was strictly correct, in that we won't ever *see* sniffing because SSL is in place, whereas I interpreted this incorrectly perhaps as SSL *stopped* sniffing. Subtle distinctions can sometimes matter. So please ignore the previous email, unless a cruel and unusual punishment is demanded... iang On Wednesday 01 June 2005 16:24, Ian G wrote:
On Tuesday 31 May 2005 19:38, Steven M. Bellovin wrote:
In message <200505311831.15142.iang@systemics.com>, Ian G writes:
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
In message <427CCA9B.29132.760A1FC@localhost>, "James A. Donald" writes:
-- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
First, you mean "the Web PKI", not PKI in general.
The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL.
I think you meant to write that James' reasoning is circular, but strangely, your reasoning is at least as unfounded - correlation not causality. And I think the evidence is pretty much against any causality, although this will be something that is hard to show, in the absence.
Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement.
Well, I'm not arguing it is technically hard. It's just un-economic. In the same sense that it is not technically difficult for us to get in a car and go run someone over; but we still don't do it. And we don't ban the roads nor insist on our butlers walking with a red flag in front of the car, either. Well, not any more.
So I stand by my statement - correlation is not causality.
* AFAICS, a non-trivial proportion of credit card traffic occurs over totally unprotected traffic, and that has never been sniffed as far as anyone has ever reported. (By this I mean lots of small merchants with MOTO accounts that don't bother to set up "proper" SSL servers.)
Given what a small percentage of ecommerce goes to those sites, I don't think it's really noticeable.
Exactly my point. Sniffing isn't noticeable. Neither in the cases we know it could happen, nor in the areas. The one place where it has been noticed is with passwords and what we know from that experience is that even the slightest security works to overcome that threat. SSH is overkill, compared to the passwords mailouts that successfully protect online password sites.
* We know that from our experiences of the wireless 802.11 crypto - even though we've got repeated breaks and the FBI even demonstrating how to break it, and the majority of people don't even bother to turn on the crypto, there remains practically zero evidence that anyone is listening.
FBI tells you how to do it: https://www.financialcryptography.com/mt/archives/000476.
Sure -- but setting up WEP is a nuisance. SSL (mostly) just works.
SSH just works - and it worked directly against the threat you listed above (password sniffing). But it has no "PKI" to speak of, and this discussion is about whether PKI protects people, because it is PKI that is supposed to protect against spoofing - a.k.a. phishing.
And it is PKI that makes SSL "just doesn't set up." Anyone who's ever had to set up an Apache web server for SSL has to have asked themselves the question ... "why doesn't this just work" ?
As for your assertion that no one is listening, I'm not sure what kind of evidence you'd seek. There's plenty of evidence that people abuse unprotected access points to gain connectivity.
Simply, evidence that people are listening. Sniffing by means of the wire.
Evidence that people abuse to gain unprotected access is nothing to do with sniffing traffic to steal information. That's theft of access, which is a fairly minor issue, especially as it doesn't have any economic damages worth speaking of. In fact, many cases seem to be more accidental access where neighbours end up using each other's access points because the software doesn't know where the property lines are.
Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct.
But this is totally incorrect! The spyware installs on the users' machines, and thus does not need to sniff the wire. The assumption of SSL is (as written up in Eric's fine book) that the wire is insecure and the node is secure, and if the node is insecure then we are sunk.
I meant precisely what I said and I stand by my statement. I'm quite well aware of the difference between network sniffers and keystroke loggers.
OK, so maybe I am incorrectly reading this - are you saying that spyware is being delivered that incorporates wire sniffers? Sniffers that listen to the ethernet traffic?
If that's the case, that is the first I've heard of it. What is it that these sniffers are listening for?
Eric's book and "1.2 The Internet Threat Model" http://iang.org/ssl/rescorla_1.html
Presence of keyboard sniffing does not give us any evidence at all towards wire sniffing and only serves to further embarrass the SSL threat model.
As for DNS hijacking -- that's what's behind "pharming" attacks. In other words, it's a real threat, too.
Yes, that's being tried now too. This is I suspect the one area where the SSL model correctly predicted a minor threat. But from what I can tell, server-based DNS hijacking isn't that successful for the obvious reasons (attacking the ISP to get to the user is a higher risk strategy than makes sense in phishing).
They're using cache contamination attacks, among other things.
...
As perhaps further evidence of the black mark against so-called secure browsing, phishers still have not bothered to acquire control-of-domain certs for $30 and use them to spoof websites over SSL.
Now, that's either evidence that $30 is too much to pay, or that users just ignore the certs and padlocks so it is no big deal anyway. Either way, a model that is bypassed so disparagingly without even a direct attack on the PKI is not exactly recommending itself.
I agre completely that virtually no one checks certificates (or even knows what they are).
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
James A. Donald wrote:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
asymmetric cryptography has a pair of keys ... the other of the key-pair decodes what has been encoding by one of them. a business process was defined using this technology where one of the key-pair is designated as public ... and freely distributed and the other of the key-pair is designated as confidential and never divulaged. an authentication business process was defined using public/private business process called digital signature .... where a hash of a message is taken and encoded with the private key. the recipient can recompute the hash of the received message and compare it to the digital signature that has been decoded with the corresponding public key. this catches whether the message has been altered and from 3-factor authentication http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are implies "something you have" authentication ... i.e. the originator has access and use of the corresponding private key. PKI was somewhat targeted at the offline email model of the early 80s; the relying party dials up their (electronic) post office, exchanges email, and hangs up. They then may be dealing with first time correspondance from a total stranger with no (offline or online) recourse for determining information about the sender. Relying parties could be seeded with trusted public key repository of trusted third party certification authorities. Stangers could be issued "certificates" (digitally signed by one of these certification authorities) containing informoation about themselves bound to their public key. Email recipients in the offline email days of the early 80s ... could now of source of information regarding first time communication from total strangers (sort of the "letters of credit" model from the sailing ship days). we were asked to work this small client/server startup in menlo park http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 that wanted to do payments on something they called a commerce server. In the year we worked with them ... they moved from menlo park to mountain view and changed their name (trivia question ... who previously had the rights to their new name? also what large corporate entity was providing most of the funding for the commerce sever?). some topic drift ... recent postings referencing this original e-commerce work as an example of service oriented architecture (SOA): http://www.garlic.com/~lynn/2005i.html#42 http://www.garlic.com/~lynn/2005i.html#43 they had this technology called SSL which was configured at addressing two issues: a) is the webserver that the user had indicated to the browser ... the actual webserver the browser was talking to and b) encryption of the transmitted information. SSL digital certificates would be issued http://www.garlic.com/~lynn/subpubkey.html#sslcert which would contain the domain name of the webserver bound to their public key. the browsers would have trusted public key repository seeded with the public keys of some number of trusted third party certification authorities. the browser SSL process would compare the domain name indicated by the user to the domain name in the digital certificate (after validating the certificate). (at least) two (other) kinds of vulnerabilities/exploits have shown up. 1) in the name of convenience, the browsers have significantly obfuscated the certificate operation from the end-user. attackers have devised ways for the end-users to indicate incorrect webservers ... which the browser SSL process (if it is even invoked) will then gladly validate as the webserver the user indicated. 2) a perceived issue (with knowing that the webserver that a browser is talking to is the webserver the user indicated) were integrity issues in the domain name infrastructure. however, as part of doing this consulting with this small client/server startup ... we also had to do detailed end-to-end business process due dilligence on some number of these certification authorities. it turns out that a certification authority typically has to check with the authoritative agency for the information they are certifying. the authoritative agency for domain name ownership is the domain name infrastructure ... the very institution that there are integrity questions giving rise to the requirement for SSL domain name server certificates. In the second vulnerability, the certification authority industry is somewhat backing a proposal that when somebody registers a domain name with the domain name infrastructure ... they also register their public key. then in future communication with the domain name infrastructure, they digitally sign the communication. the domain name infrastructure then can validate the digital signature using the (certificateless) public key onfile for that domain. This supposedly improves the integrity of the communication between the domain name owner and the domain name infrastructure .... mitigating some possible domain name hijacking exploits (where some other organization becomes recorded as the domain name owner). It turns out that the certification authority industry also has an issue. When somebody makes an application for an SSL domain name certificate, they need to supply a bunch of identification information. This is so the certification authority can perform the expensive, time-consuming and error-prone identification process ... and then do the same with the information on file at the domain name infrastructure as to the owner of the domain name ... and then see if the two domain name owner identifications appear to match. Having an on-file public key for the domain name owner ... the certification authority industry can also require that an SSL domain name applicant, digitally sign their application. Then the certification authority can retrieve the onfile (certificateless) public key and change an expensive, error-prone, and time-consuming identification process into a simple and more reliable authentication process (by retrieving the onfile public key and validating the digital signature). From an e-commerce perspective ... the SSL process was to protect against credit card information havesting for use in fraudulent transactions. However, the major vulnerability/exploit before SSL and after the introduction of SSL ... wasn't against credit card information in flight ... but against huge repositories of credit card information (information at rest). It was much easier for the crooks to steal the information already collected in huge repositories than go to the effort of evesdropping the information inflight and creating their own repositories (fraud return-on-investment, much bigger benefit in stealing large repositories of already collected and organized information). related reference regarding security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 the financial standards working group, x9a10 was given the task of preserving the integrity of the financial infrastructure for all retail payments (as well as some number of other requirements) for x9.59 standard http://www.garlic.com/~lynn/index.html#x959 so some earlier work on PKI-oriented protection for retail payments involved digitally signed transaction oriented protocol with attached digital certificates. in the early 90s, there was some work on x.509 identity certificates. however, there was some issues with ceritifcation authorities predicting exactly what information might be needed by unknown future relying parties ... and so there was some direction to grossly overload these certificates with excessive amounts of personal information. In the mid-90s, some number of institutions were starting to realize that such overloaded repositories of excessive personal information representing significant liability and privacy issues. As a result you saw some retrenchment to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo these were digital certificates that basically contained some kind of database record locator (like an account number) bound to a public key (the database record contained all the real information). however, it became trivial to demonstrate that such relying-party-only certificates were redundant and superfluous. This was, in part because they violated the original design point for certificates ... the relying party not having any other recourse to the necessary information. By definition if all the information was in a relying-party's database ... then by definition the certificate was redundant and superfluous. in this later part of the mid-90s payment scene, these relying-party-only certificates were on the order of 4k-12k bytes. It turns out that a typical retail payment message is 60-80 bytes. Not only were the stale, static, relying-party-only certificates redundant and superfluous ... but they also would contribute to enormous payload bloat (on the order of one hundred times). the other problem with the relying-party-only, redundant and superfluous, stale, staic, enormous payload-bloat digital certificate based infrastructure ... were that they effectively were targeted only at protecting credit card information "in-flight" ... something that SSL was already doing. They were providing no countermeasure for the major vulnerability to the data "at rest". the information at rest was still vulnerable (and was the major exploit already with or w/o SSL) So one of the things in the x9a10 financial standards working group was to do a treat and vulnerability analysis ... and design something that could preserve the integrity of the financial infrastructure for all retail payments (credit, debit, stored-value, online, offline, pos, etc). X9A10 defined a light-weight digitally signed transaction that wouldn't contribute to the enormous payload bloat of the stale, static, redundant and superfluous certificate-based infrastructures. Another issue was the analysis demonstrated that the major treat and vulnerability was to the data at rest. So for X9.59, a business rule was defined ... for account numbers used for X9.59 transactions ... only correctly verified digitally signed transactions (authenticated) could be authorized. An x9.59 transaction was digitally signed, and the relying party could use an on-file public key to validate the digital signature .... showing the transaction wasn't modified in transit and providing "something you have" authentication as to the originator (they had access and use of the corresponding private key). furthermore, evesdropping of the transaction in flight ... and/or harvesting the large transaction databases (information at rest) wouldn't yield information for the crook to perform a fraudulent transaction. the current exploits where knowledge from an existing transaction is sufficient to generate fraudulent transaction has gone away ... for vulnerabilities involving both "data in flight" as well as "data at rest". The issue wasn't that SSL being designed to protect data-in-flight ... the issue was that the major threat/vulnerability has been to "data-at-rest" ... so to some extent, SSL (and the various other countermeasures to "data-in-flight" vulnerabilities) wasn't responding to the major threats. To some extent, e-commerce/internet was opening a theoritical, new vulnerabilities ("data-in-flight") compared to the non-internet world ... and so SSL was somewhat theoritically demonstrating that e-commerce/internet use wouldn't make the situation any worse. Recent studies have indicated that at least 77% of the id theft exploits have involved insiders (supporting the long standing premise that the majority of fraud is by insiders). The introduction of e-commerce and internet have introduced new avenues for attacking data-at-rest by outsiders. As a result, e-commerce/internet potential threats to data-at-rest has contributed to obfuscating responsible insiders in cases of exploits against data-at-rest. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
participants (5)
-
Anne & Lynn Wheeler -
Ben Laurie -
Ian G -
James A. Donald -
Steven M. Bellovin