Re: A mighty fortress is our PKI
://developer.mozilla.org/En/Same_origin_policy_for_JavaScript I admit there are areas of XS* in practice which I do not understand perfectly. Can anyone think of a specific vulnerability here? As for config problems, you have to weigh the risk of downtime due to running your web presence in one datacenter versus running it at 15+ locations simultaneously via Anycast. There is always going to be a risk of _something_ happening that can take your site offline. Running high volume or high profile sites out of multiple locations seems to be a growing practice though. CDNs running anycast are facing another big problem: There's not much IPv4 space left to go around. To run anycast you'll need to have a /24 at a minimum. Even if you put one SSL certificate on each of your spare IP addresses, you're only going to be able to run 254 certificates per block. What if you eventually have a few thousand customers? Two realities deserve explicit mention: 1) Most CDNs are new entities, started up long after the days when individuals could get their own giant netblock assignments. Most CDNs are not sitting on their own /16s. 2) Most CDN customers are big enough to be running an SSL certificate on their main site, and if they are serving all their images and other media content via the CDN, they will _need_ to have SSL on the CDN or they're going to run into Insecure mixed content warnings when their HTTPS content refers to HTTP content on the CDN. Should having an SSL certificate on your CDN cost you more per month than your bandwidth costs, and consume lots of IPv4 space? What is an appropriate amount of SAN entries in one certificate? Are two unrelated domains too many? What about twenty or fifty? I can tell you at the moment that we're considering putting a cap of somewhere between 25 and 50 on the number of SAN entries allowed in one certificate. Would that solve the problem? I'd really like more feedback on how to improve this. (For the TLS folks, SNI (a client-supplied Server Name Indication when it connects) won't fix this because (a) it's not widely-enough supported yet and (b) the server admin would have to buy 107 separate certificates to do the job that's currently done by one Sybil certificate, and then repeat this for every other Sybil certificate they use). True for (a) which makes it a bit of a show stopper for SNI at the moment, but (b) is not so problematic due to the internal automation that is likely to be a pre-requisite for managing many certificates across multiple locations. I appreciate the chance to participate in the discussion. We're very open to considering the risks, and not afraid to make changes based on feedback like this. From my call with Edgecast I can tell you they feel the same way, and they're willing to make changes to improve. All the best, Paul Tiemann CTO, DigiCert, Inc. - 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
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 Jul 26, 2010, at 10:22 PM, Chris Palmer wrote: 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. I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all Get the top 5 browsers to support it, and a lot of that any CA can issue to any domain risk goes way down. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? Would it give too much confidence to people whose DNS is being spoofed? 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 Great slides! The TOFU/POP is nice, and my favorite concept was to translate every error message into a one sentence, easy-to-understand statement. 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 10:58 PM, d...@geer.org wrote: Wow, I was just going to recommend Dan's book, Security Metrics. It is actually Andy Jaquith's book, I only wrote the intro. Ouch, I'm sorry for the mistake! (I knew I remembered your name in connection with the book, but it's on my bookshelf in the office and I was at home.) In the meantime, though, couple of years ago I did a tutorial on security metrics which you may find useful http://geer.tinho.net/measuringsecurity.tutorial.pdf Thanks, my favorite so far is page 45 with the table on Risk Management Culture. I need to tape that to the wall for inspiration. Pathologic: Don't want to know Bureaucratic: May not find out Generative: Actively seek Pathologic: Failures punished Bureaucratic: Local repairs only Generative: Failures beget reforms From my point of view: The security community is being Generative (Actively seek) about finding the flaws in systems, but it's too often in the Pathologic (Failures punished) stage about how to handle those flaws once they're discovered. My suspicion: It's fun to Actively seek, and hard to find solutions, and it can be downright frustrating to champion reforms. If the vulnerability isn't gigantic, it's hard to even get people to listen. Reform is maybe 20x harder and 1/5th as fun as poking the holes. That said, here's an experience worth talking about: Dan Kaminsky did a pretty good job of being Generative in _both_ categories. He found a hole in DNS, and then worked with LOTS of vendors and even with people not directly tied to DNS to collaborate on reforms. He even called me (at a smaller CA) to make sure we were aware of the risks and to verify that we don't only rely on automated forms of verification. I really appreciated the call--it felt like my chance to talk to a rock star. All the best, Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 9:51 AM, Peter Gutmann wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. This isn't true for all OCSP services. For example, DigiCert's is not CRL based, so it really can say Yes and it really can say Unknown meaningfully. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). True for off-the-shelf OCSP responders that base themselves on CRL. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
