Re: A mighty fortress is our PKI
Perry E. Metzger writes: All major browsers already trust CAs that have virtually no security to speak of, ...and trust any of those CAs on any (TCP) connection in the (web app) session. Even if your first connection was authenticated by the right CA, the second one may not be. Zusmann and Sotirov suggested SSL pinning (like DNS pinning, in which the browser caches the DNS response for the rest of the browser process' lifetime), but as far as I know browsers haven't implemented the feature. A presentation I've given at a few security gatherings may be of interest. I cover some specific security, UI/UX, and policy problems, as well as some general observations about incentives and barriers to improvement. Our overall recommendation is to emulate the success of SSH, but in a browser-y, gentle-compliance-with-the-status-quo-where-safe way. https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs Eckersley's and Burns' presentation at Defcon (coming right up) will present their findings from a global survey of certs presented by hosts listening on port 443. Their results are disturbing. Ivan Ristic is also presenting his results of a survey at Black Hat on the 29th. I don't know anything about his findings. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann writes: Since this is a certificate we (DigiCert) have issued, I'm trying to understand if there is a vulnerability here that's more apparent to others than to me, If an attacker can steal the cert by any means, perhaps by means particular to one of the hosted sites, he can now forge the identities of the 100+ sites. It gives the attack a multiplier. (It appears 100+ is not even the largest number of entities in a single cert.) Potential attacks: * Attack the server (e.g. buffer overflow in FooHTTPD or some other bug in a web app the CDN runs (I know not all CDNs run cloud app hosting services, but some do)). Note that even though all sites are served by the same server, all sites suffer the risk profile of the highest-profile site. If a CDN server is serving tiny.unknown.com and also mega.often-attacked.net, tiny.unknown effectively endures attacks on mega.often-attacked. * Questionable reseller. Although reselling a CDN might normally give you access only to a subset of the CDN's subscriber's sites, you can get many in one go because these certs have so many subjects. See below. The bulk of the FQDNs included in the certificate are for subdomains like media., www-cdn., static., and the like. Apply a different test: Is it bad for various organizations to use the same CDN for services over http? Is it bad for all those different FQDNs to CNAME to the same DNS entry and point to the same IP address? Is it bad for a CDN to host multiple individual SSL certificates for its customers on the same set of hardware? Let's just say I'd rather get the advantages of a CDN by other means, but that I recognize that using a CDN can be a reasoanble economic trade-off in many situations. If not, then what is so abhorrent about their various FQDNs being included in a single SSL certificate? I wouldn't say abhorrent, but the increased size of the cert could be a concern. I just wiresharked an HTTPS connection to https://ne.edgecastcdn.net/. The cert is 7,044 bytes. Admirably small given how many names are in it, but still 6 KB larger than another cert I observed containing only one subject. I have a hard enough time convincing people that HTTPS is not the root of their web app performance problems and that therefore they CAN afford to use it; the last thing we need is a certificate that big increasing latency at a critical time in the page load. TLS sessions to that server don't seem to last very long either, increasing the frequency of cert delivery; but maybe that is necessary due to the high traffic such a server handles. (Gotta have a limit on the size of the session store.) I know it's a small thing, especially relative to the general content layer heft of most sites, but still. When trying to convince developers to use HTTPS, I need every rhetorical advantage I can get. :) Considering the business incentives landscape, is it safe to assume a strong incentive for a CDN running all those sites to be vigilant about their own server security? Are there any inherently skewed incentives that I'm just not seeing which would lead a CDN to be negligent in its management of its network security and the SSL certificates it manages? As Peter noted, http://www.webhostingtalk.com/showthread.php?t=873555. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: [...] This is kind of a long message to reply to so I'll just post a meta-reply to avoid getting bogged down in nitpicking, the message, as the subject line indicated, was intended to start a discussion on some of the weaknesses inherent in the SSL and commercial PKI model. I consciously worded it to avoid mentioning any CA names, and only mentioned Edgecast because it was impossible not to (I had to provide a URL for the cert), and even then included a disclaimer that it wasn't a criticism of Edgecast. I actually agree with a lot of the points made in the response, since this wasn't a failing of Edgecast or a CA but a problem in the way SSL's PKI (or more generally just PKI as a whole) works. Because it was designed for the purposes of authenticating a single user to the global X.500 directory it really doesn't have any provision for Sybil certs (I'm going to keep calling them that because we need some sort of label for them :-). The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. So a general response to the several well, what would you do? questions is I'm not sure, that's why I posted this to the list. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. I've spoken with my contacts at Edgecast, and they expressed that they're very willing to consider alternate approaches. I'm not actually sure what the fix would be for this, or even if there is a fix that needs to be made. Thus the hope to get it discussed on the list. (Oh, and a comment on the XS* bit, that was based on an earlier off-list discussion on messing with Firefox' same-origin policy protection mechanism and isn't relevant here, the real issue is the more obvious one of a single cert acting for large numbers of totally unrelated domains with very different security requirements). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Ian G i...@iang.org writes: ** But talking about TLS/SNI to SSL suppliers is like talking about the lifeboats on the Titanic ... we don't need it because SSL is unsinkable. ... or talking to PKI standards groups about adding a CRL reason code for certificate issued in error (e.g. to an imposter). This was turned down because CA's never make mistakes, so there's no need to have such a reason code. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Hi, Eckersley's and Burns' presentation at Defcon (coming right up) will present their findings from a global survey of certs presented by hosts listening on port 443. Their results are disturbing. Have these results already been published somewhere, or do you maybe even have a URL? Ralph - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 10:11 AM, Peter Gutmann wrote: So a general response to the several well, what would you do? questions is I'm not sure, that's why I posted this to the list. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. long ago and far away, we were called in to consult with a small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL that they wanted to use. As part of applying the technology to the business payment process ... we also had to go around and investigate how some of these new businesses, calling themselves Certification Authorities, operated. In any case, the result is now sometimes called electronic commerce. There were lots of issues with deficiencies and vulnerabilities, resulting in my coining the term merchant comfort certificates ... aka ... as opposed to anything to do with security. Of course, I also suggested that everybody that in anyway touched on the certificates or the merchant servers ... needed to have detail FBI background check. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 11:04 AM, Anne Lynn Wheeler wrote: long ago and far away. they had also invented this technology called SSL that they wanted to use. As part of applying the technology to the business payment process ... we also had to go around and investigate how some of these new businesses, calling themselves Certification Authorities, operated. In that same time, I was at CyberCash, we invented what is now sometimes called electronic commerce. and that and $5 will get you a cup of coffee. We predated SSL by a few years. Used RSA768 to protect DES sessions, etc. Usual stuff. One complaint that we got a lot was that we did not use certs or CAs. CyberCash was the only trusted source. There were lots of issues with deficiencies and vulnerabilities Most of which we avoided by skipping the cert concept. Still, better technology has nothing to do with business success. Public Key Crypto with out all the cruft of PKI. Its still a good idea. Pat -- Pat Farrell http://www.pfarrell.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 12:09 PM, Pat Farrell wrote: Most of which we avoided by skipping the cert concept. Still, better technology has nothing to do with business success. Public Key Crypto with out all the cruft of PKI. Its still a good idea. that became apparent in the use of SSL between all the merchant servers and the payment gateway. by the time the registration and setup process was completed at both ends ... the certificate was purely an artificial attribute of the crypto library being used. there were other issues with the payment gateway protocol ... i was able to mandate things like mutual authentication ... which didn't exist in the crypto library up to that point ... however the exchange of certificates was so engrained that it wasn't possible to eliminate (even tho all the necessary information already existed at both end-points). the merchant server/browser part ... I could only recommend ... I couldn't mandate. my analogy is that certificates PKI are electronic analogy of the letters of credit/introduction from the sailing ship days ... when the relying party had no other recourse for information about the stranger that they were dealing with. This was left over from the dail-up email days of the early 80s (dial-up electronic post-office, exchange email, hangup, and possibly have first-time email from complete stranger). that design point was quickly vanishing in the 90s with the pervasive growth of the online internet. I as at annual ACM sigmod conference in the early 90s ... and one of the big sessions, somebody asked on of the panelists what was all this x.50x gorp about. Eventually somebody explained that it was a bunch of networking engineers attempting to re-invent 1960s database technologies with certificates being armored, stand-alone, stale representation of some information from a database someplace. In the later 90s, certificates attempted to find place in no-value market niches (aka, situations involving no-value operations that couldn't justify online /or real-time information) ... although this got into some conflicts ... trying to address no-value market-niche ... at the same time claiming high-value, expensive operation. There were businesses cases floated to venture community claiming $20B certificate market ... i.e. that every person in the country would have $100/annum certificate ... some predicting that the financial community would underwrite the cost. When that didn't happen, there were other approaches. We had been called in to help wordsmith the cal. state electronic signature legislation ... which was being heavily lobbied by the PKI industry to mandate certificates. I could that rube-goldberg OCSP was response to interaction I had with some of the participants ... somebody bemoaning the fact that the financial industry needed to be brought into 20th century requiring certificates appended to every financial transaction. I responded that stale, static certificates would be retrenching to before the advent of online, real-time point-of-sale payment transactions ... aka a major step backward, not a step forward. Besides the appending a stale, static certificate to every payment transaction being redundant and superfluous ... it also represents enormous overhead bloat. There were some reduced financial, relying-party-only certificates being floated in the mid-90s ... which were still 100 times larger than the typical payment payload size (increase the size of payment transaction payload by a factor of 100 times for no beneficial purpose). The X9 financial standard group ... had some participants recognizing the enormous overhead bloat certificates represented in payments started a compressed certificate standards activity ... possibly looking to reduce the 100 times overhead bloat to only 5-10 times overhead bloat (although still redundant and superfluous). One of their techniques was that all information that was common in every certificate ... could be eliminated. Then all information that the relying party already had could be eliminated. I was able to trivial show, that a relying party would have access to every piece of information in a certificate ... and therefor digital certificates could be compressed to zero bytes. Then rather than arguing whether it was mandated that every payment transaction have an appended certificate ... we could mandate that every payment transaction have a zero-byte appended certificate. disclaimer ... eventually had a couple dozen (assigned, retain no interest) patents in the area of certificate-less public key (some showing up long after we were gone) ... summary here http://www.garlic.com/~lynn/aadssummary.htm -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Ralph Holz writes: Eckersley's and Burns' presentation at Defcon (coming right up) will present their findings from a global survey of certs presented by hosts listening on port 443. Their results are disturbing. Have these results already been published somewhere, or do you maybe even have a URL? Defcon is the publishing event; and Black Hat for Ristic's material. It's in a few days (Friday evening for Ekersley and Burns). Also keep an eye on the eff.org site, I bet they'll say something there too. Possibly also at isecpartners.com. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 12:09 PM, Pat Farrell wrote: In that same time, I was at CyberCash, we invented what is now sometimes called electronic commerce. and that and $5 will get you a cup of coffee. We predated SSL by a few years. Used RSA768 to protect DES sessions, etc. Usual stuff. somewhat as result of doing the SSL payment stuff ... in the mid-90s got invited to be part of the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 retail payment financial standard ... which was specific in such a way that it would work with any secure authentication (including allowing both certificate certificate-less mode). The business process was slightly tweaked so it was no longer necessary to hide the information in a payment transaction to preserve the financial infrastructure integrity. This didn't eliminate skimming, evesdropping, data breaches ... but it eliminated the ability for the attackers to use the information to perform fraudulent transactions (and effectively also eliminates the major use of SSL in the world ... hiding the information in financial transaction). About the same time the x9a10 standards work was going on ... there were a couple other payment transaction specification work occurring ... which were mandating certificate operation ... somewhat trying to side-step the 100 times payload bloat. they would strip the certificate at internet gateway ... and forward the transaction thru the standard payment network with flag turned on (they could somewhat wave their hands that 100 times payload bloat on the internet was immaterial ... but not so in the real payment network) that certificate processing had occurred (compared to light-weight, super secure, x9.59 ... which operated end-to-end). There were later some presentations at ISO standards meetings that transactions were showing up with the certificate flag on ... but they could prove no certificate had been involved (i.e. there was financial interchange fee benefit motivating turning on the flag). shortly after they had published their (certificate-based) payment specification (but well before any operational code), I did a public-key op profile for their specification. I then got a friend that had a optimized BSAFE library (ran four times faster) to benchmark the profile on lots of different platforms ... and then reported the results to the groups publishing the profile. The response was my numbers were 100 times too slow (if they had actually run any numbers, their comment should have been it was four times too fast). Some six months later when they did have pilot code ... my profile numbers were within a couple percent of actual (i.e. the BSAFE library changes had been incorporated into standard distribution). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Sampo Syreeni writes: I am not sure what quantitative measurement of vulnerability would even mean. What units would said quantity be measured in? I'm not sure either. This is just a gut feeling. See also: http://nvd.nist.gov/cvsseq2.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, 27 Jul 2010 11:11:52 -0700 Chris Palmer ch...@noncombatant.org wrote: Sampo Syreeni writes: I am not sure what quantitative measurement of vulnerability would even mean. What units would said quantity be measured in? I'm not sure either. This is just a gut feeling. See also: http://nvd.nist.gov/cvsseq2.htm That scale seems remarkably arbitrary. One problem with such arbitrary scales is that there is no objective methodology one can engage in which will show that the equation is wrong in some way. Unless you can perform an experiment to falsify the self-declared objective quantitative security measurement, it isn't science. I can't think of an experiment to test whether any of the coefficients in the displayed calculation is correct. I don't even know what correct means. This is disturbing. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Perry E. Metzger writes: Unless you can perform an experiment to falsify the self-declared objective quantitative security measurement, it isn't science. I can't think of an experiment to test whether any of the coefficients in the displayed calculation is correct. I don't even know what correct means. This is disturbing. I can recommend a good single-malt scotch or tawny port if you like. Have you tried the Macallan 18? False metrics are rampant in the security industry. We really need to do something about them. I propose that we make fun of them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
False metrics are rampant in the security industry. We really need to do something about them. I propose that we make fun of them. You might consider joining us in D.C. on 10 August at http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon5.0 --dan, program committee - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 27/07/2010 15:11, Peter Gutmann wrote: The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. Haven't we already decided what to do: SNI? -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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 majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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 majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, Jul 27, 2010 at 09:54:51PM +0100, Ben Laurie wrote: On 27/07/2010 15:11, Peter Gutmann wrote: The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. Haven't we already decided what to do: SNI? But isn't that the problem, that SNI had to be added therefore it isn't everywhere therefore site operators don't trust its presence therefore SNI is irrelevant? Do we have any information as to which browsers in significant current use don't support SNI? Hopefully at some point site operators could declare that browsers that don't support SNI will not be supported. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. I like that idea, as long as a verifiable timestamp is included. Without a trusted timestamp, would the bad guy be able to backdate the signature? Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Jul 27, 2010, at 1:14 PM, d...@geer.org wrote: False metrics are rampant in the security industry. We really need to do something about them. I propose that we make fun of them. You might consider joining us in D.C. on 10 August at http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon5.0 --dan, program committee Wow, I was just going to recommend Dan's book, Security Metrics. Anyone tasked with quantifying actual security should read his book. There's a pretty good dissection of ALE, and a fantastic few chapters about building a balanced scorecard to measure your operations from more perspectives than just dollars and cents. When I read that nist.gov link, the joke about the spherical cow popped into my head. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Haven't we already decided what to do: SNI? But isn't that the problem, that SNI had to be added therefore it isn't everywhere therefore site operators don't trust its presence therefore SNI is irrelevant? It appears Apache supports SNI as of 2.2.12 which was released 12 months ago. Do we have any information as to which browsers in significant current use don't support SNI? Hopefully at some point site operators could declare that browsers that don't support SNI will not be supported. The worst of the show stoppers is IE on Windows XP. No SNI support. IE6 is still at 7.2% as of June 2010. It was 14.4% in June 2009. http://www.w3schools.com/browsers/browsers_stats.asp ... is it possible to help IE6 and other non-SNI browsers to die faster? Perry suggested reading Orwell's essay, Politics and the English Language. Think about Orwell's opening sentence: Most people who bother with the matter at all would admit that the English language is in a bad way, but it is generally assumed that we cannot by conscious action do anything about it. Now replace the English language with PKI Then... There is a long list of flyblown metaphors which could similarly be got rid of if enough people would interest themselves in the job; and it should also be possible to laugh the not un- formation out of existence*... *One can cure oneself of the not un- formation by memorizing this sentence: A not unblack dog was chasing a not unsmall rabbit across a not ungreen field. So... There is a long list of outdated browsers which could be got rid of if enough people would interest themselves in the job. One fast way to pressure technological change is for the world to move on to better things and leave the legacy stuff behind. Who uses Netscape 4 or IE 5 any more? Those were left behind because everyone in web design wanted CSS support and just started using CSS. The web design field desperately wants to be throwing IE6-is-dead parties. Could some intelligent web designers come up with a few snippets of code in the various web flavors (PHP, ASP, JSP, etc) for people to easily install and include on their sites (as part of a movement to discourage old browser usage and encourage better security on the web...) If an old browser is detected, a friendly warning message or even an error message appears, along with links to the site explaining the movement... Of course it would only be grassroots, but I've heard enough rumbling on web designer blogs to think that someone might just take up a cause like that. The security community could encourage it maybe? Put a Paypal button on there. I know a lot of people who would donate money. Looks like at least one site is out there: http://ie6update.com/ but has no Paypal donate button, and doesn't offer newcomers the reasons they should switch to something more modern. Maybe this is too utopian. But laughing does work, sometimes. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
** But talking about TLS/SNI to SSL suppliers is like talking about the lifeboats on the Titanic ... we don't need it because SSL is unsinkable. Apache support for this came out 12 months ago. Does any one know of statistics that show what percentage of installed Apache servers out there are running 2.2.12 or greater? How many of the top 10 Linux distributions are past 2.2.12? A CDN might be able to push SNI forward for its own platform, but mass adoption isn't coming until we also have broad compatibility among the client browsers. SSL certs as they are currently being used are not good for much if they cause a bunch of browser warnings, so I can't see how you could really expect SSL suppliers to blast holes in their own Titanic. New standards are wonderful, but who can use them until they're well supported? This page says iPhone IOS4 supports SNI. That just came out. http://en.wikipedia.org/wiki/Server_Name_Indication ... or talking to PKI standards groups about adding a CRL reason code for certificate issued in error (e.g. to an imposter). This was turned down because CA's never make mistakes, so there's no need to have such a reason code. I wasn't around when this happened, but maybe revoking for Key compromise was considered just as good. And maybe it's rare enough not to need its own special if() statement in all the browsers. The browsers don't really do different things based on the reason code anyway (to my knowledge) Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, Jul 27, 2010 at 06:07:02PM -0600, Paul Tiemann wrote: IE6-is-dead parties. Could some intelligent web designers come up with a few snippets of code in the various web flavors (PHP, ASP, JSP, etc) for people to easily install and include on their sites (as part of a movement to discourage old browser usage and encourage better security on the web...) If an old browser is detected, a friendly warning message or even an error message appears, along with links to the site explaining the movement... Already exists: http://code.google.com/p/ie6-upgrade-warning/ - JS, displays a nice dialog telling the user why they should upgrade and links to download a new IE, Firefox, Chrome, etc. http://drupal.org/project/iedestroyer - Drupal (CMS) plugin http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Or a block of pretty much plain old HTML: http://www.codingforums.com/showthread.php?t=196674 Ultimately though, the only thing that's going to get some people off IE6 is the machines they are running it off of finally dying, either due to hardware failure or being so badly owned by worms that the machine becomes inoperable, at which point it goes into the trash and they buy a new one. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, Jul 27, 2010 at 06:30:51PM -0600, Paul Tiemann wrote: ** But talking about TLS/SNI to SSL suppliers is like talking about the lifeboats on the Titanic ... we don't need it because SSL is unsinkable. Apache support for this came out 12 months ago. Does any one know of statistics that show what percentage of installed Apache servers out there are running 2.2.12 or greater? How many of the top 10 Linux distributions are past 2.2.12? Yet browser SNI support is what matters regarding adoption. No hosting service will provision services such that SNI is required if too much of the browser installed base does not support it. Of course server support is a requirement in order to get SNI deployed, but that's much less of an issue than client support. Thanks for pointing out IE6 though. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Hi Peter, I actually agree with a lot of the points made in the response, since this wasn't a failing of Edgecast or a CA but a problem in the way SSL's PKI (or more generally just PKI as a whole) works. Yes. SNI could have been included from the start, but it was probably hard enough back then to get SSL 1.0 or SSL 2.0 out the door. It's difficult for a CA to push new SSL extensions if SSL clients aren't ready for what's new. Because it was designed for the purposes of authenticating a single user to the global X.500 directory it really doesn't have any provision for Sybil certs (I'm going to keep calling them that because we need some sort of label for them :-). Agreed. PKI was designed in a time when IPv4 space was a lot more plentiful too, and few had even dreamt of serving from multiple locations via anycast. A lot of the time (for good or bad) new pressures form around a problem and people invent new ways of using old things. It's often easier to reuse an older well supported feature of BGP, TCP or even SSL than to go invent something wonderful and new and then wait years for the world to catch up (think SNI.) The designers of PKI couldn't foresee all possible future uses, and implementation wasn't perfect from the start. It wasn't until 2007 that the Subject Alternative Name started to see mass adoption, and that was due mainly to Microsoft pushing for it (they had supported it since Windows 95!) which ought to be considered a good thing. I won't object to 'Sybil' as long as it's understood to mean multi-personality and not deception. The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. I'll admit that at first it appeared to have been posted as something to be laughed at. After reading Perry's recommended Orwell essay, I'm willing to admit that laughing at things can be a way to effect change. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. Part II was nice. Shocking and full of thought provoking questions too. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. My technical contention is that it's generally going to be harder to compromise an origin caching CDN host because they do not run any web app code at all: Pseudo code for a CDN http daemon: init while 1: read a request if already cached: serve the request from cache else: fetch from origin, save to cache if cacheable, and serve If running PHP/ASP/Java/etc then those bets are off, but a CDNs don't do this. Many CDNs just serve up static (non-origin cached, no POST support) sites. I've spoken with my contacts at Edgecast, and they expressed that they're very willing to consider alternate approaches. I'm not actually sure what the fix would be for this, or even if there is a fix that needs to be made. Thus the hope to get it discussed on the list. Well, if nothing else, the smaller certificates might at least help whatever PKI library was getting the segv. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 2010-07-28, Peter Gutmann wrote: ... or talking to PKI standards groups about adding a CRL reason code for certificate issued in error (e.g. to an imposter). This was turned down because CA's never make mistakes, so there's no need to have such a reason code. Personally what I wonder about is that there is precious little research on how difficult and/or worthwhile it is to circumvent the formal, mathematical crypto-stuff, as a whole. We all know that is bound to be the hardest part if somebody wants to hurt you, so why center your attention there? Why not go for the soft flesh instead? Perry already caught me on that basic security questionnaire, when I asked for numbers and couldn't answer. Now I'm thinking the proper figure should probably be ratio of investment into a security break, against benefit from the same. Including existing safeguards against said break. That should be fair enough, and should help us optimize against future security breaks at the margin, no? -- Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com