Re: man in the middle, SSL ... addenda 2
so the assertion in the previous post http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL was that sitekey as being introduced because of shortcomings in SSL countermeasures to man-in-the-middle attacks however sitekey only deals with simple impersonation and is easily defeated with a man-in-the-middle attack in earlier post http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL there was reference to SSL attempting to address man-in-the-middle attacks and "are you really talking to the server that you think you are talking to". however, SSL might be better characterized as verifying that the operator of the webserver is the owner of the corresponding domain name ... aka a digital certificate & pki operation demonstrates that the operator of the webserver has use of the private key that corresponds to the "public key" in the digital certificate ... bound to the domain name. The browser than validates that the domain name in the URL is the same as the domain name in the (validated) digital certificate. one of my assertions is that problems cropped up when the public started associating webservers with buttons that they clicked on ... significantly degrading any association in most of the publics' mind between URLs and the webserver. Since the public weren't effectively associating URLs with webservers ... and the only function provided by SSL (as countermeasure to man-in-the-middle attacks) was validating the correspondence between the URL and the webserver a widening security gap exists between the "buttons" that the public associate with webservers and the URL, which is the unit of validation by SSL one conclusion is if countermeasures are introduced that don't actually address the actual security vulnerabilities ... then they may not be able to eliminate those security vulnerabilities. so one countermeasure that has been introduced (to close some part of the security gap) is by some of the email clients which look for "buttons" in the content ... and if the label of the button appears to be a url/http ... it checks if the actual url/http is the same as the claimed url/http. if they don't match ... the email client will flag the email as potential problem. The simple countermeasure by attackers ... is to not use a http/url label for the button (i.e. just label the button something else, say the name of some financial institution). Another kind of approach trying to close the gap between what the people associate with webservers and the actual URL used ... is to take a page out of PGP and have a list of "trusted" urls (or at least domain names). Browsers display the assigned trust level recorded for that domain name used in the URL (and then SSL verifies that the webserver contacted is actually the webserver for that URL). This would start to provide a mechanism for closing the gap between what the public deals with and the part of the infrastructure being checked by SSL. (at least) two problems with this approach: 1) a repository of URL trust levels is almost identical to a trusted public key repository (directly used by PGP). the repository could directly record both the URL, the public key for that URL as well as the associated trust level. this would be another demonstration of digital certificates being redundant and superfluous in an online world and would provide the basis for a more trusted environment than the current SSL operation misc. past posts mentioning certificateless public key operation http://www.garlic.com/~lynn/subpubkey.html#certless 2) so the new (old) attack is social engineering attempting to get people to click on various buttons that change the trust level in their local trust repository. however, that also exists today ... social engineering to get people to load certification authority digital certificates into their local (certificate authority public key) repository. so number #1 doesn't eliminate all possible attacks ... however, it actually addresses one of the identified security vulnerabilities/attacks ... as opposed to supplying "fixes" for things other than what is actually broken. lots of past posts mentioning ssl domain name certificates including posts in long thread about the certificates providing more of a feeling of "comfort", as opposed to actually security, integrity, trust, etc. http://www.garlic.com/~lynn/subpubkey.html#sslcert note that #1, in attempt to close the gap between what the public associates with websites ... and what is SSL is validated for a website (i.e. some chance that the operator of a webserver reached by the domain name in the URL is the same as the owner of that domain name) ... it can actually close some of the gaps ... but in doing so, it increases the need for endpoints with some level of integrity ... a
Re: man in the middle, SSL
Leichter, Jerry wrote: > Recall how SiteKey works: When you register, you pick an image (from a > large collection) and a phrase. Whenever you connect, the bank will > play back the image and phrase. You aren't supposed to enter your > password until you see your own image and phrase. i.e. it is a countermeasure to a impersonation attack ... not a man-in-the-middle (impersonation). all it presumably attempts to address is "are you talking to the website you think you are talking to" ... which is the same thing that SSL countermeasure to man-in-the-middle is supposed to be doing. man-in-the-middle can defeat simple impersonation countermeasures by impersonating the server to the client and impersonating the client to the server ... and (somewhat) transparently passing traffic in both directions. requiring the server to present unique "something you know" authentication information is then straight forward for man-in-the-middle by having access to the "real" server. i would contend that the issue for introducing sitekey ... was that SSL wasn't adequately protecting against man in the middle attacks ... i.e. previous posts http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda http://www.garlic.com/~lynn/[EMAIL PROTECTED] man in the middle, SSL ... however, i contend that sitekey isn't even designed to be countermeasure against man-in-the-middle attacks ... it only is a countermeasure against simple impersonation attacks ... so it isn't even addressing the short-comings in SSL that (my opinion) gave rise for the need for sitekey in the first place. the other issue is that "your own image and phrase" is a shared secret (and a flavor of static "something you know" authentication) ... so it presumably requires similar practices required for password shared secrets ... if it had turned out to significantly address SSL short-comings (mitm-attacks) and saw wide deployment then presumably you would need a unique flavor for every unique security domain (ala password shared secrets). The implication then is that it would scale as poorly as password shared secret paradigm. previous post mentioning that the paradigm might scale as poorly as other shared secret based authentication implementations http://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules misc. posts mentioning man-in-the-middle attacks http://www.garlic.com/~lynn/subintegrity.html#mitm misc. posts mentioning shared secret (authentication) paradigm http://www.garlic.com/~lynn/subintegrity.html#secret - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: man in the middle, SSL
| somewhat related | Study Finds Bank of America SiteKey is Flawed | http://it.slashdot.org/it/07/02/05/1323243.shtml Recall how SiteKey works: When you register, you pick an image (from a large collection) and a phrase. Whenever you connect, the bank will play back the image and phrase. You aren't supposed to enter your password until you see your own image and phrase. The usability problem found in the study was that if you build a login page with the image and phrase replaced by something else that seems to go that - like a notification about a systems upgrade, or maybe an ad for a bank service - most people (90%?) will just go ahead and enter their password anyway. Unfortunately, the "all ads all the time" nature of today's web sites has conditioned people not to expect *anything* to remain constant. We're used to judging the trustworthiness of those with interact with in the real world by various invariant marks and other features. If you go to your bank and find the signs have all changed, you will at the least be a bit suspicious. At a web site - who would think twice? SiteKey tries to use something that's invariant but unique to you. That's a distinction people clearly don't make automatically. Whether with sufficient training and experience they will learn to do so remains to be seen. (BofA is very consistent in telling you *never* to enter your password without first checking for your image and phrase. Clearly, though, it hasn't clicked for people.) Of course, SiteKey isn't the full answer - if I know your login name, I can try to log in to BofA and get a copy of your image and phrase. What SiteKey at best prevents is broad-based non-personalized attacks. Automating "skimming" of SiteKey information using some virus is a plausible attack, and we'll see it eventually if it appears worth someone's while. Combined with some of the other reports coming out about the lack of effectiveness of EV cert indicators (why *that* surprises anyone is beyond me) and of pretty much every other technique that anyone has proposed so far, it's clear that the battle against phishing is going to be long and hard, and that victory is very far from clear. In architecture, there is the notion of a building have "human scale". Places built ignoring that notion feel overwhelming. (Sometimes that's the point, of course.) The Internet, as it's evolved to this point, clearly lacks "human scale". People's intuitions quick responses, all the things we've evolved and learned to deal with the real world, don't match the world of the web. Until we can figure out how to bring human capabilities and limitations into the picture much more effectively and thoroughly than we have so far, things are going to get much worse. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: man in the middle, SSL
somewhat related Study Finds Bank of America SiteKey is Flawed http://it.slashdot.org/it/07/02/05/1323243.shtml Study Finds Security Flaws on Web Sites of Major Banks http://www.nytimes.com/2007/02/05/technology/05secure.html?ref=business The Emperor's New Security Indicators http://www.usablesecurity.org/emperor/ from above: We evaluate website authentication measures that are designed to protect users from man-in-the-middle, "phishing", and other site forgery attacks. We asked 67 bank customers to conduct common online banking tasks. Each time they logged in, we presented increasingly alarming clues that their connection was insecure. First, we removed HTTPS indicators. Next, we removed the participant's site-authentication image---the customer-selected image that many websites now expect their users to verify before entering their passwords. Finally, we replaced the bank's login page with a warning page. After each clue, we measured whether participants entered their passwords or withheld them. ... snip ... somewhat the issue ... from previous posts in this thread: http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL and recent post/thread from early last month on the subject http://www.garlic.com/~lynn/2007b.html#53 http://www.garlic.com/~lynn/2007b.html#54 ... originally SSL was going to prevent man-in-the-middle attack because the person knew the website that they were going to talk to and the corresponding URL. They would enter that URL into the browser and the browser would validate that the contacted website was in fact the website for that URL (assuming the entered URL was HTTPS and not HTTP) early on, SSL was perceived to be too expensive, and so relegated it to just checkout/payment. now the user entered URL with HTTP and the website wasn't validated ... so could be man-in-the-middle. at some point the user clicked on https (checkout/payment) button provided by the website. now instead of HTTPS validating that the user was talking to the webserver that they thot they were talking to ... HTTPS was validating that the webserver was whatever webserver that the webserver was claiming to be (since the webserver was providing both the HTTPS URL and the SSL digital certificate). so as the user convention of clicking on provided buttons proliferated ... the cracks/gaps widened between what webserver the user thot they were talking to and the webserver they might actually be talking to (since there was less & less a connection between what they thot of as a browser and the URLs that were being validated by SSL). So one of the possible countermeasures was for a website to provide unique "something you know" authentication ... i.e. something hopefully only you knew (so you had higher degree of confidence that you were actually talking to the website you thot you were talking to. The problem was that if the communication was already talking to man-in-the-middle website impersonation ... there is nothing that would prevent the man-in-the-middle from impersonating the website to the consumer ... and impersonating the consumer to the actual website. Effectively, by definition for man-in-the-middle, the man-in-the-middle transparently passes communication in both directions (except possibly modifying URLs and internet addresses contained in the traffic as needed). in effect, the mechanism is a countermeasure to simple website impersonation attacks ... but not to website man-in-the-middle attacks. other refs http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"? http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007 misc. past posts mentioning man-in-the-middle attacks http://www.garlic.com/~lynn/subintegrity.html#mitm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: man in the middle, SSL
[I prefer to keep discussions on-list where possible. CCing the list.] Beryllium Sphere LLC wrote: > Bruce Schneier pointed out years ago that it's trivial for a virus > or Trojan to add a new trusted CA to the browser's list of trusted > roots. At least one "advertising support web accelerator" installs > itself in the browser configuration as a peer of Verisign and can > then proxy SSL without any warning to the user. Right. I was talking about the kind of MITM where an attacker is physically between your machine and the SSL destination, such as sitting on your network's egress. MOYM (man on your machine) attacks are a bit of a lost cause with most modern OS environments, though I've been working pretty hard to try and change that on the One Laptop per Child machines. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: man in the middle, SSL ... addenda
re: http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL basically digital certificates were designed as the electronic equivalent for offline distribution of information ... paradigm left over from the letters of credit and letters of introduction out of the sailing ship days (and earlier). as things moved into the online age ... certification authorities and digital certificates moved into generic low-value/no-value market segment. this is the difference between a generic employee badge for door entry ... that is identical for all employees ... vis-a-vis doing stuff specific and tailored to each employee. this is somewhat the x.509 identity certificate example mentioned in the original post ... from the early 90s ... overloaded with personal information and paradigm that promoted repeatedly spaying the identity certificates all over the world. by the mid-90s, it was starting to dawn that such a paradigm wasn't such a good idea ... and there was retrenchment to "relying-party-only" certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which basically only contained public key and some sort of record location (which contains the "real" information). however, in the payment sector ... even these truncated relying-party-only certificates still represented enormous payload and processing bloat http://www.garlic.com/~lynn/subpubkey.html#bloat especially when it was trivial to demonstrate that you could have the public key along with all the other necessary information in the designated record ... and that the digital certificate was redundant and superfluous. This is also somewhat the scenario raised in the domain name infrastructure for on-file public keys creating a significant "catch-22" for the ssl domain name certification authority industry http://www.garlic.com/~lynn/subpubkey.html#catch22 ... just upgrade the existing domain name infrastructure with on-file public keys (a requirement also suggested by the ssl domain name certification authority industry) ... but that can quickly result in a certificate-free, public key infrastructure http://www.garlic.com/~lynn/subpubkey.html#certless also the reference from 1981 http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network i.e. for the most part now ... SSL is just be using to prove that you have some valid domain name ... and the domain name you claim is the domain name you have ... this is somewhat equivalent to the low-value door badge readers to simply check are you some valid employee ... w/o regard to any higher value scenario requiring specific detail about which valid employee. so one of the points i repeated raise is that while digital certificates (as representation of some certification) is part of an offline paradigm construct ... and in the migration of the world to online environment ... digital certificates have attempted to find place in the no-value/low-value market niches ... that as soon as there is some online component (like record locater) ... it then becomes trivial to show that such digital certificates become redundant and superfluous. so SSL domain name infrastructure was originally primarily to address what came to be called electronic commerce (and still may be the primary use) for: 1) is the browser actually talking to the webserver that the person thinks it is talking to and 2) hide (encrypt) the account number during transmission over the internet. there have been some number of technical implementation vulnerabilities with respect to SSL and things like MITM-attacks ... but the big business process issue was that the deployment fairly early changed from "is the browser actually talking to the webserver the person thinks it is talking to" ... to "the browser is talking to the webserver that the webserver claims to be" (since the same webserver was supplying both the URL and the digital certificate confirming the webserver supplied URL). The second feature of ssl (encrypting to hide transmitted account numbers) was somewhat to put transactions flying over the anarchy of the world-wide Internet ... on "level play field" with the transactions that flew over dedicated telephone wires. However, the major vulnerability during that period ... and continuing today ... wasn't evesdropping the transaction during public transmission ... but vulnerabilities at the end-points which SSL does nothing to address. The end-point webservers somewhat increased vulnerabilities (compared to non-internet implementations) since a lot of the transaction logs became exposed to attacks from the internet. This matter is slightly debatable since the long term studies ... continuing up thru at least recently is that seventy percent of the resulting fraudulent transactions involve some sort of "insider". So 1) the resulting major deployments of SS
Re: man in the middle, SSL
James Muir wrote: > I was reading a hacking blog today and came across this: > > http://www.darknet.org.uk/2007/02/odysseus-win32-proxy-telemachus-http-transaction-analysis/ > > >> Odysseus is a proxy server, which acts as a man-in-the-middle during >> an HTTP session. A typical HTTP proxy will relay packets to and from >> a client browser and a web server. Odysseus will intercept an HTTP >> session’s data in either direction and give the user the ability to >> alter the data before transmission. >> >> For example, during a normal HTTP SSL connection a typical proxy will >> relay the session between the server and the client and allow the two >> end nodes to negotiate SSL. In contrast, when in intercept mode, >> Odysseus will pretend to be the server and negotiate two SSL >> sessions, one with the client browser and another with the web >> server. >> >> As data is transmitted between the two nodes, Odysseus decrypts the >> data and gives the user the ability to alter and/or log the data in >> clear text before transmission. >> >> You can find more and download Odysseus here: >> >> http://www.bindshell.net/tools/odysseus > > It is my understanding that SSL is engineered to resist mitm attacks, so > I am suspicious of these claims. I wondered if someone more familiar > with SSL/TLS could comment. > > Isn't in the case that the application doing SSL on the client should > detect what this proxy server is doing and display a warning to the user? If the user's browser is configured to accept a CA cert for which the proxy holds the signing key, then the proxy can generate a (bogus) cert for the destination site on the fly, and this will be transparent to the user. Scott - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: man in the middle, SSL
James Muir wrote: It is my understanding that SSL is engineered to resist mitm attacks, so I am suspicious of these claims. I wondered if someone more familiar with SSL/TLS could comment. Isn't in the case that the application doing SSL on the client should detect what this proxy server is doing and display a warning to the user? My oft repeated comment about when we were asked to consult with this small client/server startup that wanted to do payments on servers and had this technology called SSL ... http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 The browser was to check that what the person typed in ... matched the domain name in the digital certificate that the server provided (that the server that the client thot they were talking to was the server that they were talking to). There was some other ancillary things that we were interested in ... that the digital certificate actually represented something more ... i.e. it was issued by the acquiring financial institution that financially stood behind the merchant since the merchant was already paying a lot of money to cover doing business. however, that never happened ... so the digital certificate just represents that it belongs to the owner of the domain. this issue is somewhat touched on in this blog posting http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again? in this blog https://financialcryptography.com/mt/archives/000863.html However, early on, merchant webservers found that that doing SSL for the whole shopping experience cut their thruput by something like 80-90 percent ... so the industry fairly quickly switched to just using SSL for the payment/checkout portion when you click on their button. Now the URL is being provided by the server (button) ... not by the client, as a result the effect is no longer "is the client talking to the server that the client thinks they are talking to" ... since the server is supplying both the URL and the digital certificate ... the result is "the server is the server that the server claims to be" (unless it is a really dumb crook/attacker). It isn't sufficient for their to be "ssl certificates" to be countermeasure to MITM-attack, the security process has to include that the server is validated against something the client supplies ... not that the server is validated against something the server supplies (i.e. i can prove that i am whoever i claim to be ... not that i can prove that i am who you think i am). This is also behind a lot of the phishing stuff ... that the attacker can claim to be something ... and provide a field/button for you to click on ... the SSL certificate then just proves that the server matches the URL provided by the field/button; since the attacker supplier field/button is producing the URL ... and not the client ... it takes advantage of the difference, for a MITM-attack ... between the opening/crack opened by what is claimed for the button and what the URL actually is ... since only the URL is being validated by the SSL certificate ... not what the client thinks is claimed for the field/button. some more comments in these posts: http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"? http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007 lots of past posts mentioning MITM-attacks http://www.garlic.com/~lynn/subintegrity.html#mitm i.e. you have to understand the end-to-end business process (of security) ... where all the cracks are ... and just which (of possibly large number) MITM vulnerability ... that you have specifically created a countermeasure for. so one of the things that we did as part of early deployment (of this stuff that has since come to be called electronic commerce) was go around and do some detailed end-to-end audits of these emerging operations that were calling themselves certification authorities and producing these things that were being called SSL domain name digital certificates. At the time, we coined this term "certificate manufacturing" to try and differentiate what was happening http://www.garlic.com/~lynn/subpubkey.html#manufacture and what was in the literature about "public key infrastructure" ... for a little topic drift ... proposal from 1981 for a (small i) infrastructure: http://www.garlic.com/~lynn/2006w.html#12 more secure communcation over the network Part of the "audits" was figuring out just what it was they were doing as part of the process that they were calling "certification" ... as the business process supporting the technology that produced the actual digital certificates (i.e. a credential/certificate that is a stand-in representation of that certification they were performing). this gave rise to a lot of comments/observations about if the domain name infrastructure actually provided a direct, higher integrity operation ... it would
Re: man in the middle, SSL
Am Freitag, den 02.02.2007, 16:15 -0500 schrieb James Muir: > > You can find more and download Odysseus here: > > > > http://www.bindshell.net/tools/odysseus > > It is my understanding that SSL is engineered to resist mitm attacks, > so > I am suspicious of these claims. I wondered if someone more familiar > with SSL/TLS could comment. > > Isn't in the case that the application doing SSL on the client should > detect what this proxy server is doing and display a warning to the > user? A unmodified SSL/TLS client should display a warning message, that the server certificate is invalid or something similar. So this is not a valid man in the middle attack agains SSL/TLS. Perhaps you are going to use this tool for debugging purpose. If so, you can perhaps generate a certificat with a private key. The certificate is installed in your SSL/TLS client as a trusted certification authority and the certificate and the private key is then used by odysseus to make this warning messages go away. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: man in the middle, SSL
James Muir wrote: > It is my understanding that SSL is engineered to resist mitm attacks, so > I am suspicious of these claims. I wondered if someone more familiar > with SSL/TLS could comment. > Isn't in the case that the application doing SSL on the client should > detect what this proxy server is doing and display a warning to the user? There's nothing new or interesting about this; SSL MITM tools have been around for a long time. When you're connecting to a website via SSL, you have no out of band knowledge of the certificate that the server is supposed to use (e.g. you can't query DNS and get the certificate fingerprint). SSL clients generally do three checks on the server cert: they verify it's still valid on today's date, that the name in the cert matches the server you're connecting to, and that you trust the CA that issued the cert. An SSL MITM proxy can trivially satisfy two of those three checks. If an attacker had sufficiently strong incentive and a specific target site, presumably he could satisfy the third as well (get a "trusted" CA to sign a bogus cert for the server in question -- remember Microsoft from a few years back). So yes, in the general case, the web browser will notice the MITM, and inform the user that two checks pass and one fails. And almost all users will hit "continue" and not care, because they don't understand SSL or the risks involved. They shouldn't have to, either; it's for this reason that I think SSL is just altogether broken in the way we use it on the web. It passes the technical requirements, but utterly fails at being a usable security technology. -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
man in the middle, SSL
I was reading a hacking blog today and came across this: http://www.darknet.org.uk/2007/02/odysseus-win32-proxy-telemachus-http-transaction-analysis/ Odysseus is a proxy server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP proxy will relay packets to and from a client browser and a web server. Odysseus will intercept an HTTP session’s data in either direction and give the user the ability to alter the data before transmission. For example, during a normal HTTP SSL connection a typical proxy will relay the session between the server and the client and allow the two end nodes to negotiate SSL. In contrast, when in intercept mode, Odysseus will pretend to be the server and negotiate two SSL sessions, one with the client browser and another with the web server. As data is transmitted between the two nodes, Odysseus decrypts the data and gives the user the ability to alter and/or log the data in clear text before transmission. You can find more and download Odysseus here: http://www.bindshell.net/tools/odysseus It is my understanding that SSL is engineered to resist mitm attacks, so I am suspicious of these claims. I wondered if someone more familiar with SSL/TLS could comment. Isn't in the case that the application doing SSL on the client should detect what this proxy server is doing and display a warning to the user? -James -- James Muir http://www.scs.carleton.ca/~jamuir - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
