Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Earlier in the discussion there were questions about why a service provider would want to MITM their customers. This has now been answered by a service provider: It's to protect the children. From http://patrick.seurre.com/?p=42 Three's policy with regards to filtering is intended to ensure that children are protected from inappropriate content when using the internet on their phones [...] This is not about intercepting customer communications but is about the safety of children who use our network. Note that while they're using Bluecoat hardware to do it, there's no mention of SSL MITM'ing. Another interesting point in the post: In addition I asked Three why they were wasting money on Bluecoat's services when any webmaster worth his salt knows how to tailor the webpage provided based on the IP address of the PC making the request. They could produce a page full of innocent images for Bluecoat when they come calling, but save all the unsavoury material for the .real. visitor. This is already standard practice for malware-laden sites, to the extent that it's severely affecting things like Google Safe Browsing and Facebook's link scanner, because Google and Facebook always get to see benign content and only the end user gets the malware. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
* Adam Back: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Such CAs do exist, but to my knowledge, they are enterprise-internal CAs which are installed on corporate devices, presumably along with other security software. Even from a vendor point of view, this additional installation step is desirable because it fits well with a per-client licensing scheme, so I'm not sure what the benefit would be to get a certificate leading to one of the public roots. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 6/12/11 21:52 PM, Florian Weimer wrote: * Adam Back: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Such CAs do exist, but to my knowledge, they are enterprise-internal CAs which are installed on corporate devices, presumably along with other security software. Even from a vendor point of view, this additional installation step is desirable because it fits well with a per-client licensing scheme, so I'm not sure what the benefit would be to get a certificate leading to one of the public roots. The promise of PKI in secure browsing is that it addresses the MITM. That's it, in a nutshell. If that promise is not true, then we might as well use something else. If the reality is that it simply makes the MITM a sellable feature, that's a breach of the promise. If the situation is we'll protect you from some MITMs and we'll sell other MITMs over you ... it's a breach of the original terms that were foisted on browsing in the first place... Now, this doesn't necessarily mean that some MITMs can't be justified. It's more that the original promise is what the users believe. And exceptions like this aren't really tolerated in the beliefs of users. So, we need that debate: what's an exception? what's tolerable? what's the point? We need to see those MITM certs. So we can understand what the nature of the breach is. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Yes, Peter said the same, BUT do you think they have a valid cert chain? Or is it signed by a self-signed company internal CA, and the company internal CA added to the corporate install that you mentioned... Thats the cut off of acceptability for me - full public valid cert chain on other peoples domains for MitM thats very bad. Internal cert chain via adding cert to browser - corporate can go for it, its their network, their equipment to install software on! (Bearing in mind its the corporate intention to keep other people off their network with firewalls, network auth etc). One claim by Lucky if I recall is that the new trend in bring your own device (iphone, android, ipad etc) starts to cause a conflict - becomes complicated for the corporate to expect to install certs into all those browsers. They no longer control the OS/app install. I think thats true - but in effect if your environment is that security conscious, you probably should not be allowing BYOD anyway - who knows what malware is on it, bypassing your egress is completely _trivial_ with software, or even just config of software. And anyway since when does your minor inconvenience of installing certs authorize you or CAs to subverting the SSL guarantee and other people's security. Even people who have internal CAs for certification SHOULD NOT be abusing them for MitM. Adam On Tue, Dec 06, 2011 at 10:52:43AM +, Florian Weimer wrote: * Adam Back: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Such CAs do exist, but to my knowledge, they are enterprise-internal CAs which are installed on corporate devices, presumably along with other security software. Even from a vendor point of view, this additional installation step is desirable because it fits well with a per-client licensing scheme, so I'm not sure what the benefit would be to get a certificate leading to one of the public roots. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 6 Dec, 2011, at 3:43 AM, ianG wrote: The promise of PKI in secure browsing is that it addresses the MITM. That's it, in a nutshell. If that promise is not true, then we might as well use something else. Is it? I thought that the purpose of a certificate was to authenticate the server to the client. This is a small, but important difference. If you properly authenticate the server, then (one hopes) that we've tacitly eliminated both an impersonation attack and a MiTM (an MiTM is merely a real-time, two-way impersonation). The problem is that we're authenticating the server by naming, and there are many entities with a reason to lie about names. There are legitimate and illegitimate reasons to lie about names, and while we know that it's going on, we don't have a characterization of what reality even *is*. We're seeing this in this very discussion. I also want to see proof that this is going on. I know it is, but I want to see it. These bogus certs are a lot like dark matter -- we know they're there, but we have little direct observation of them. Jon ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
This is already standard practice for malware-laden sites, to the extent that it's severely affecting things like Google Safe Browsing and Facebook's link scanner, because Google and Facebook always get to see benign content and only the end user gets the malware. This is the single greatest side effect of a personalized web -- what you see depends on who you are. Like that is good or something. --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
d...@geer.org writes: This is already standard practice for malware-laden sites, to the extent that it's severely affecting things like Google Safe Browsing and Facebook's link scanner, because Google and Facebook always get to see benign content and only the end user gets the malware. This is the single greatest side effect of a personalized web -- what you see depends on who you are. Like that is good or something. It's always interesting to see how the bad guys adopt some technologies much faster than the good guys. Another example beyond this one is intelligent agents for interacting with online services, which exist mostly as research papers and projects. And banking trojans. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On Tue, 6 Dec 2011 12:34:37 +0100 Adam Back a...@cypherspace.org wrote: Kids figure this stuff out getting through site restrictions on school wifi also. Some schools try to block popular web games.. eg runescape. Let us not discourage either the children or the schools! This sounds like an excellent way for children to pick up some technical skills and to learn about computer security. If we must condition our children to think that censorship is the norm, at least we can also provide them with some decent education in the process. -- Ben -- Benjamin R Kreuter UVA Computer Science brk...@virginia.edu -- If large numbers of people are interested in freedom of speech, there will be freedom of speech, even if the law forbids it; if public opinion is sluggish, inconvenient minorities will be persecuted, even if laws exist to protect them. - George Orwell signature.asc Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011-12-05 14:58, Sandy Harris wrote: Peter Gutmannpgut...@cs.auckland.ac.nz wrote: You have to be inside the captive portal to see these blue-pill certs. This is why various people have asked for samples, because only a select lucky few will be able to experience them in the wild. I am in China. How could I test whether the Great Firewall's packet sniffers have such a cert.? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography If you are in China, you probably have a vpn through the great firewall into a tax haven. If you have software that detects change in certs, login with and without your vpn. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 12/05/2011 04:21 AM, Lucky Green wrote: On 2011-12-04 12:09, Ondrej Mikle wrote: [...] I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason, about month after Peter Eckersley did. Result was the same (counting trusted CAs). Plus few others (some seemed to be internal company CAs; but did not chain to a trusted root). Ondrej, Most (but not all) of the CAs that I worked with over the years did not have anybody on the operations side full time that would know how to place a revocation reason into the CRL. Which is why the majority of CRL entries include an unspecified reason code or the ever popular reason code NULL. Matches my observations, especially when looking at CRLs of some small CAs (company internal). I had a hunch some of those revocations could be due to CA compromise, but from my point of view it is be only a speculation. I appreciate sharing your experience working with CAs, it gives me a bit more understanding in my guesswork how they operate internally :-) Without taking anything away from the work of the folks at the EFF (I appreciate their effort and have been a long-time financial supporter of the EFF), determining the number of CA compromises from looking at CA Compromise in reason codes is like determining car theft statistics from the number of car thieves that turn themselves in at the police station. Of course, those marked 'CA compromise' are just the detected and admitted cases (a lower bound). However should I claim any other revocations were due to CA compromise I'd have to back that claim with some evidence. It does not require disclosing of any confidential information to come to the conclusion that more certificates have been revoked due to CA compromise than certs were issued due to CA compromise. Indeed, you only need to look through the database for certs that very publicly have been revoked due to CA compromise to find a some that lack that reason code in the CRL. Can you elaborate on the part of coming to the conclusion that revocation was due to CA compromise? In the first sentence, should the last part say ...than certs were revoked citing CA compromise as the reason? (I'm having trouble parsing it) My first idea would be to look for a batch of certs revoked in a short time period when looking for CA compromise. The hunch I wrote above is based on my short period (about 7 years ago) working part-time for a company that did a lot of IT projects for government institutions. One of the projects was a pilot application for eGovernment (which included PKI and CA-ish stuff). Before that project I was tasked with penetration testing for said company, so I had pretty good idea how a hacker could obtain access. There was lot of bad blood between management and developers, experienced people left, inexperienced developers were responsible for gaping security holes. The company's use of bribes to secure government contracts was an open secret (company has gone bankrupt since then). Did some of the CAs you worked for exhibit similar atmosphere like the company above? I'm asking because in such environment people simply wouldn't be motivated enough to really care about breaches and competent people wouldn't stay there for long. Also, a friend once mentioned he had direct access to RA/CA interface at a telco operator issuing certs that chained to Verisign for some project (him being project manager from another company). That gave me impression that such interfaces are probably more common than an uninitiated outsider might think. Is that guess correct? Lastly, I am not trying to insinuate that having your CA compromised is or should ever become a crime. I agree here. Also CA claiming to have no compromise just might be the case of not being able to detect one or be lying (which is way worse). That's why I did not name CAs from the CRLs (wouldn't be a good motivation to keep them honest about revocation reasons). Ondrej ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Ondrej Mikle ondrej.mi...@nic.cz writes: Matches my observations, especially when looking at CRLs of some small CAs (company internal). I had a hunch some of those revocations could be due to CA compromise, but from my point of view it is be only a speculation. I appreciate sharing your experience working with CAs, it gives me a bit more understanding in my guesswork how they operate internally :-) So I'm going to invoke the Carl Ellison if you think that's bad rule (stated approximately as whenever someone tells a horror story about PKI, someone else will come along with 'if you think that's bad...') and mention a trusted root CA that went out of business (I tracked its root key through three resales but I have no idea who has it now) where not only did no-one who was left know how to put reason codes in CRLs, there was no-one who actually knew how to issue a CRL. So if you had a cert from them you could pretty much do whatever you wanted with it (until it expired naturally) because there was no way to revoke it. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
In general it looks like it's a mixture of it's configurable and it depends on the vendor (the above only tells you what Bluecoat do). Interesting to note that the Bluecoat hardware has problems MITM-ing Windows Update, because Microsoft apply the quite sensible measure of only allowing something signed by a known Windows Update cert (or at least on a Microsoft-supplied trust list), rather than any old cert that turns up as long as it's signed by some CA somewhere. I've heard of a similar approach proposed for smartphone mobile banking apps, you hardcode in a cert that's used to verify a whitelist of known-good certs for banks (more or less like Microsoft's CTLs), and then it doesn't matter what certs the CAs sign because if it's not on the CTL then it doesn't get trusted. Sounds similar to the mechanism which allowed detection of the DigiNotar breach by Chrome: http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html Two major players using certificate pinning to provide additional security where CAs let us down. There may just be a lesson in there ... -C ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
This thread is amazing. I've known just a fractions/hints of the practices described here. Few comments/questions inline/below. On 12/04/11 07:37, Lucky Green wrote: Concur. The standard sub-CA contracts contain a right to audit the number of certs issued, like any enterprise-wide software license agreement does include a right to audit used seats. Not once in over 30 years have I seen such an audit performed. There is no reason to audit: when you buy a sub-CA, the public CA's rep will work out a contract that gives you the right to use as many certs and more as you conceivably could use given the application to which you plan to put the sub-CAs. Keeping count of actual certs issued would only add cost to both the sub-CA customer and the root CA provider. There is simply no business case for auditing the number of certs issued. On 12/02/11 11:02, Peter Gutmann wrote: It's not just a claim, I've seen them too. For example I have a cert issued for google.com from such a MITM proxy. I was asked by the contributor not to reveal any details on it because it contains the name and other info on the intermediate CA that issued it, but it's a cert for google.com used for deep packet inspection on a MITM proxy. I also have a bunch of certs from private- label CAs that chain directly up to big-name public CAs, there's no technical measure I can see in them anywhere that would prevent them from issuing certs under any name. How do MitM boxes react when they MitM connection to a server with self-signed cert (or cert issued by an obsure CA not trusted by MitM box)? Do the boxes send to client also an auto-generated self-signed cert that generates warning or re-sign it so that client sees valid chain? MitM-re-signing an unverifiable chain of server to a chain that's trusted at the MitM-ed client would be hilarious, allowing to MitM a MitM box (though this would be an easily avoidable mistake to make). Given the state of security/auditing of private sub-CAs as described, was there ever a report of a breach (e.g. stolen key, fraudulently issued certs)? blatant_CA_bashing While chasing data from my scans around, I checked history of few CAs. Most oddly hilarious trusted CA is probably SAIC (Science Applications International Corporation). Reason: SAIC led the development of Trailblazer Project for NSA (in my book this tops much-too-obvious CAs of other TLA agencies). Also, Network Solutions, L.L.C (also a CA) was owned by SAIC at some time. Later, Network Solutions did not acquire exactly good guy reputation. Don't get me wrong: I'm not claiming either of the mentioned CAs did anything egregious subverting CA-trust placed in them. I have no intention to single them out as shady, additional search would turn up many more CAs. /blatant_CA_bashing Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) Ondrej ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Hi, Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) We're actually about to release a little tool that does exactly that, report the encountered MitM for further scrutiny. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Ondrej Mikle ondrej.mi...@nic.cz writes: How do MitM boxes react when they MitM connection to a server with self- signed cert (or cert issued by an obsure CA not trusted by MitM box)? For one example, see http://wikileaks.org/spyfiles/docs/bluecoat/219_blue-coat-systems-reference-guide-ssl-proxy.html and http://wikileaks.org/spyfiles/docs/bluecoat/246_blue-coat-systems-deployment-guide-deploying-the-ssl-proxy.html. In general it looks like it's a mixture of it's configurable and it depends on the vendor (the above only tells you what Bluecoat do). Interesting to note that the Bluecoat hardware has problems MITM-ing Windows Update, because Microsoft apply the quite sensible measure of only allowing something signed by a known Windows Update cert (or at least on a Microsoft-supplied trust list), rather than any old cert that turns up as long as it's signed by some CA somewhere. I've heard of a similar approach proposed for smartphone mobile banking apps, you hardcode in a cert that's used to verify a whitelist of known-good certs for banks (more or less like Microsoft's CTLs), and then it doesn't matter what certs the CAs sign because if it's not on the CTL then it doesn't get trusted. Given the state of security/auditing of private sub-CAs as described, was there ever a report of a breach (e.g. stolen key, fraudulently issued certs)? You're joking, right? Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Hi, We're actually about to release a little tool that does exactly that, report the encountered MitM for further scrutiny. Great! I had some ideas how to implement and spread it, awesome to hear that that you beat me to it :-) :) It was actually Kai Engert who made the initial suggestion, and we've just followed up on it. We've proposed a talk at berlinsides, let's see if that works out. :-) Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Lucky Green shamr...@cypherpunks.to writes: If the concern is that employees receive security warnings when accessing in- house websites, the standard solution is to push out a corporate root via AD, which is transparent and works quite well. And once they get AD and/or WSUS ported to OS X and Linux it'll be even more useful :-). Another reason I've seen for in-house sub-CAs is that even if you're an all- Windows environment it may be too hard to push a private root out to everyone if there's no centralised control over everything (due to compartmentalisation/chinese walls/geographic distribution/whatever). No root CA that I have encountered requires that you operate the HSM in FIPS mode or mandates that you shall not back up the private key in the clear to a USB flash drive. I think the reason for the former is that almost no-one ever operates their hardware in FIPS mode, period. A few years ago someone who works for $global- hardware-vendor mentioned at a conference that when you buy their FIPS 140- certified hardware you need to get an optional add-on, available free for the asking, to run it in FIPS 140 mode. In the product's entire lifetime the number of requests they've had could be counted on the fingers of one hand. Another global security product vendor shipped one of their flagship products with a bug that caused it to crash when FIPS 140 mode was enabled. It took several years before anyone noticed. Every professional services team that I have worked with over the years recommended to the customers of such sub-CAs to make a backup of the private keys and store them in a safe somewhere. PKCS #12 is very popular for this. Some HSMs, quite reasonably (in the vendors' view) and quite unreasonably (in the customers' view) don't allow easy key export except via vendor-supplied mechanisms (e.g. cloning into another $10,000 HSM or storing key portions in vendor-supplied smart cards/datakeys/whatever), but if you generate the key in software and load it into the HSM via a PKCS #12 then you can back it up and share it around without the HSM getting in the way. Sometimes encrypted, sometimes in the clear, but always with the necessary decryption information (smartcards and/or PINs) in the same safe. This is what makes buying crypto gear on eBay so much fun, if you buy PKI- oriented HSMs then there'll typically be a note stuck to the crypto gear with the PIN(s) on it. You end up with all sorts of interesting signing keys that way (things like Luna CA3's aren't cheap, so only relatively high-value keys tend to get stored in them, e.g. CA keys for government departments). As with disposing of hard drives in PCs and servers, the crypto hardware lifecycle seems to stop at we unplugged it. The standard sub-CA contracts contain a right to audit the number of certs issued, like any enterprise-wide software license agreement does include a right to audit used seats. Not once in over 30 years have I seen such an audit performed. Yup, that's what I've found as well, it's just a variation on the per-seat software licensing model, except that there's no BSA. The smart purchasing manager will pay less than USD 50k. Oh, maybe I've been talking to less smart managers :-), the figures I heard started at $50K and quickly went up into six digits. Or maybe the inevitable race to the bottom has made things cheaper in the last few years. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011-12-04 18:18, Ondrej Mikle wrote: Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) You think too small. We should be trying to replace PKI, not particular badly behaved bits of the PKI infrastructure. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 12/04/11 13:08, Peter Gutmann wrote: Ondrej Mikle ondrej.mi...@nic.cz writes: How do MitM boxes react when they MitM connection to a server with self- signed cert (or cert issued by an obsure CA not trusted by MitM box)? For one example, see http://wikileaks.org/spyfiles/docs/bluecoat/219_blue-coat-systems-reference-guide-ssl-proxy.html and http://wikileaks.org/spyfiles/docs/bluecoat/246_blue-coat-systems-deployment-guide-deploying-the-ssl-proxy.html. Thanks. Given the state of security/auditing of private sub-CAs as described, was there ever a report of a breach (e.g. stolen key, fraudulently issued certs)? You're joking, right? Sorry, my bad. Mismatch in my thinking-editing coordination. Originally I wanted to ask whether you encountered a breach that was not over all the news, but a rather localized incident at the places you and Lucky described. Or heard about one from colleagues in the field (then I oversimplified the question's formulation too much). Basically I was curious what portion of similar breaches got buried from outside world. I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason, about month after Peter Eckersley did. Result was the same (counting trusted CAs). Plus few others (some seemed to be internal company CAs; but did not chain to a trusted root). I found your observations about PKI often spot on and I thought they were hyperbolically witty. I guess then you were actually not joking at all. Ondrej ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011-12-04 12:09, Ondrej Mikle wrote: [...] I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason, about month after Peter Eckersley did. Result was the same (counting trusted CAs). Plus few others (some seemed to be internal company CAs; but did not chain to a trusted root). Ondrej, Most (but not all) of the CAs that I worked with over the years did not have anybody on the operations side full time that would know how to place a revocation reason into the CRL. Which is why the majority of CRL entries include an unspecified reason code or the ever popular reason code NULL. Without taking anything away from the work of the folks at the EFF (I appreciate their effort and have been a long-time financial supporter of the EFF), determining the number of CA compromises from looking at CA Compromise in reason codes is like determining car theft statistics from the number of car thieves that turn themselves in at the police station. Sure, once in a while a fellow that has not been suspected of any crime will walk into a police station and decide to turn himself in. Every cop will have a story or two along those lines. But the number of crimes (and criminals) far exceed the number of criminals that choose to turn themselves in to the police. It does not require disclosing of any confidential information to come to the conclusion that more certificates have been revoked due to CA compromise than certs were issued due to CA compromise. Indeed, you only need to look through the database for certs that very publicly have been revoked due to CA compromise to find a some that lack that reason code in the CRL. Lastly, I am not trying to insinuate that having your CA compromised is or should ever become a crime. --Lucky Green ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Ondrej Mikle ondrej.mi...@nic.cz writes: Sorry, my bad. Mismatch in my thinking-editing coordination. Originally I wanted to ask whether you encountered a breach that was not over all the news, but a rather localized incident at the places you and Lucky described. Or heard about one from colleagues in the field (then I oversimplified the question's formulation too much). Basically I was curious what portion of similar breaches got buried from outside world. So it's a bit of a how many undetected security compromises have you had question :-). As such it's impossible to answer, although in general I would say that I doubt some of the parties involved would actually be capable of detecting a breach. So it's not a case of would they cover it up, it's how would they even know? At best you could reason by analogy, consider the typical IT-using company and their security measures, would you trust them to detect and identify an intrusion (say an SQL injection attack on their server) and notify the media and their customers so that they could take corrective action? You're now dealing with standard organisations (not even computer companies but just J.Random organisation somewhere), and this is IT Job #427, alongside more important stuff like how do your remote staff get to the Exchange server from their hotel in Bratislava and how do you get iTunes traffic through the firewall [0]. Peter. [0] Whoever coupled OS updates and whatnot with a mechanism as firewall- hostile as iTunes needs to be killed and eaten to prevent them from passing on the genes. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Sandy Harris sandyinch...@gmail.com writes: I am in China. How could I test whether the Great Firewall's packet sniffers have such a cert.? I'd be kinda surprised if they did that because it's meant to be surreptitious and the Great Firewall isn't exactly a state secret. I'd just use the Perspectives extension to warn me about odd things. Oh heck, just run Perspectives anyway no matter what. It's great for overriding Firefox' pointless browser warnings. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On Fri, Dec 2, 2011 at 1:07 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: [snip] OK, so it does appear that people seem genuinely unaware of both the fact that this goes on, and the scale at which it happens. Here's how it works: 1. Your company or organisation is concerned about the fact that when people go to their site (even if it's an internal, company-only one), they get scary warnings. 2. Your IT people go to a commercial CA and say we would like to buy the ability to issue padlocks ourselves rather than having to buy them all off you. When it is *only* company-only, I think it's much more common for companies to set up their internal CAs and just do something like an SMS or WSUS push to get their internal root CA certs into all the trusted keystores of all the company computers. I've only seen the latter case used when it involves residential customers. We can't take that the approach to force them to add our internal CA cert chain to their trust stores, and even if we could it would likely result in so many calls to the help desk to make it infeasible. However, we have occasionally used that approach with business partners. 3. The CA goes through an extensive consulting exercise (billed to the company), after which they sell the company a padlock-issuing license, also billed to the company. The company is expected to keep records for how many padlocks they issue, and pay the CA a further fee based on this. 4. Security is done via the honour system, the CA assumes the company won't do anything bad with their padlock-issuing capability (or at least I've never seen any evidence of a CA doing any checking apart from for the fact that they're not getting short-changed). Through the honor system? Does that mean that we can use a pair of dice rolled two or three times for our hardware key generation? ;-) Actually, more surprisingly, I've been told by those who manage something like this for our company, that even the reported number of padlocks that they issue and are expected to compensate the CA for is kept on the honor systemm--at least for the CA with whom we interact. (Or course, I'm assuming that the this CA retains the right to periodically do audits, etc.) -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents. -- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Well I was aware of RA things where you do your own RA and on the CA side they limit you to issuing certs belonging to you, if I recall thawte was selling those. (They pre-vet your ownership of some domains foocorp.com, foocorpinc.com etc, and then you can issue www.foocorp.com, *.foocorp.com .. however you dont get a CA private key, you get web integration with the RA so you dont have to do the email verification dance for each cert you create). Handing over a signed sub-CA is a much higher level of risk, unless perhaps it has a constraint on the domain names of certs it can sign baked into it, which is possible. To hand over a blank cheque sub-CA cert that could sign gmail.com is somewhat dangerous. But you notice that geotrust require it to be in a hardware token, and some audits blah blah, AND more importantly that you agree not to create certs for domains you dont own. Start of the thread was that Greg and maybe others claim they've seen a cert in the wild doing MitM on domains the definitionally do NOT own. (The windows 2k box sounds scary for sure, and you better hope that's not a general unrestricted sub-CA cert, but even then you could admit its similar to the security practices of diginotar.) Secure as the weakest link, and the weakest link just keeps getting lower. It would be interesting to know if there really are CAs lax enough to issue a sub-CA cert to a windows box with no hardware container for the private key. (Not that it makes that much difference... hack the RA and the private key doesnt matter so much). The real question again is can we catch a boingo or corp lan or government using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing it, and delist them. Adam On Fri, Dec 02, 2011 at 07:07:19PM +1300, Peter Gutmann wrote: Ben Laurie b...@links.org writes: They appear to actually be selling sub-RA functionality, but very hard to tell from the press release. OK, so it does appear that people seem genuinely unaware of both the fact that this goes on, and the scale at which it happens. Here's how it works: 1. Your company or organisation is concerned about the fact that when people go to their site (even if it's an internal, company-only one), they get scary warnings. 2. Your IT people go to a commercial CA and say we would like to buy the ability to issue padlocks ourselves rather than having to buy them all off you. 3. The CA goes through an extensive consulting exercise (billed to the company), after which they sell the company a padlock-issuing license, also billed to the company. The company is expected to keep records for how many padlocks they issue, and pay the CA a further fee based on this. 4. Security is done via the honour system, the CA assumes the company won't do anything bad with their padlock-issuing capability (or at least I've never seen any evidence of a CA doing any checking apart from for the fact that they're not getting short-changed). This is why in the past I've repeatedly referred to unknown numbers of unknown private-label CAs, we have absolutely no idea how many of these private-label CAs are out there or who they are or who controls them, but they're probably in the tens, if not hundreds, of thousands, and many are little more than a Windows server on a corporate LAN somewhere (and I mean that literally, it was odd to sit in front of a Windows 2000 box built from spare parts located in what used to be some sort of supplies closet and think I can issue certs that chain to $famous_ca_name from this thing :-). Going through the process is like getting a BS 7799 FIPS 140 certification, you pay the company doing the work to get you through the process, and you keep paying them until eventually you pass. The only difference is that while I've heard of rare cases of companies failing BS 7799, I've never heard of anyone failing to get a padlock-issuing license. Are people really not aware of this? I thought it was common knowledge. If it isn't, I'll have to adapt a writeup I've done on it, which assumes that this is common knowledge. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011-12-02 6:33 PM, Adam Back wrote: To hand over a blank cheque sub-CA cert that could sign gmail.com is somewhat dangerous. But you notice that geotrust require it to be in a hardware token, and some audits blah blah, AND more importantly that you agree not to create certs for domains you dont own. And we have seen how effective audits have been since Sarbannes Oxley. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Adam Back a...@cypherspace.org writes: Start of the thread was that Greg and maybe others claim they've seen a cert in the wild doing MitM on domains the definitionally do NOT own. It's not just a claim, I've seen them too. For example I have a cert issued for google.com from such a MITM proxy. I was asked by the contributor not to reveal any details on it because it contains the name and other info on the intermediate CA that issued it, but it's a cert for google.com used for deep packet inspection on a MITM proxy. I also have a bunch of certs from private- label CAs that chain directly up to big-name public CAs, there's no technical measure I can see in them anywhere that would prevent them from issuing certs under any name. (An unfortunate effect of the private-label CAs is that they contain identifying information on the organisation that uses them, something I hadn't considered in my post them to the list request, and publishing them would publicly out your employer or organisation as doing this. So I'll modify my post to the list to email them to me in private :-). The real question again is can we catch a boingo or corp lan or government using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing it, and delist them. Given that some of the biggest CAs around sell private-label CA certs, you'd end up shutting down half the Internet if you did so. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On Fri, Dec 2, 2011 at 10:02 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Adam Back a...@cypherspace.org writes: Start of the thread was that Greg and maybe others claim they've seen a cert in the wild doing MitM on domains the definitionally do NOT own. It's not just a claim, I've seen them too. For example I have a cert issued for google.com from such a MITM proxy. I was asked by the contributor not to reveal any details on it because it contains the name and other info on the intermediate CA that issued it, but it's a cert for google.com used for deep packet inspection on a MITM proxy. I also have a bunch of certs from private- label CAs that chain directly up to big-name public CAs, there's no technical measure I can see in them anywhere that would prevent them from issuing certs under any name. (An unfortunate effect of the private-label CAs is that they contain identifying information on the organisation that uses them, something I hadn't considered in my post them to the list request, and publishing them would publicly out your employer or organisation as doing this. So I'll modify my post to the list to email them to me in private :-). To what end? And, BTW, I'd like to see them too :-) The real question again is can we catch a boingo or corp lan or government using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing it, and delist them. Given that some of the biggest CAs around sell private-label CA certs, you'd end up shutting down half the Internet if you did so. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 12/01/2011 07:45 AM, James A. Donald wrote: ... We have to reconstruct our institutions for third world trust levels and southern European trust levels. Institutions characteristic of Europe and the old North America are no longer capable of functioning,... as a south European I could offer some observations on WASP trust levels and ethics in general. But it is (a) not my style and (b) not really pertinent to the mission of this list Mark R. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011 Nov 30, at 22:28 , Jon Callas wrote: On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote: I run a wonderful Firefox extension called Certificate Patrol. It keeps a local cache of certificates, and warns you if a certificate, CA, or public key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my stockbroker's web site, the warnings started to appear. Then it was just checking IP addresses and stuff. And I presume you didn't save the cert. Of course, we just need to have people look for these and then save them. Yes. I regret that I had much bigger issues at the time than saving the cert. But, honestly, this is just the most recent time I've seen it... usually when traveling. I'm sure it won't be long before someone with more time and inclination than me will see another one. sorry about that, Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2/12/11 03:26 AM, Rose, Greg wrote: On 2011 Nov 30, at 22:28 , Jon Callas wrote: On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote: I run a wonderful Firefox extension called Certificate Patrol. It keeps a local cache of certificates, and warns you if a certificate, CA, or public key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my stockbroker's web site, the warnings started to appear. Then it was just checking IP addresses and stuff. And I presume you didn't save the cert. Of course, we just need to have people look for these and then save them. Yes. I regret that I had much bigger issues at the time than saving the cert. I'm just poking around, it seems that Certificate Patrol should keep the cert. In Firefox Tools / Add-ons / Certificate Patrol / Preferences / View Certificates / getting tired now / Certificate Patrol, maybe click around here coz it didn't show the certs first time / turn off Group by Root Key / click on Stored Since to order, maybe twice / check the date in the hotel / ... time for a stiff drink / click on the cert / View / Details / Export / :-o It does store certs. It just takes above beyond to get at them. Unknown whether it stores certs that you reject. iang, now about that drink... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 12/01/2011 11:09 AM, Ben Laurie wrote: On Thu, Dec 1, 2011 at 4:56 PM, Marsh Rayma...@extendedsubset.com wrote: http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html They appear to actually be selling sub-RA functionality, but very hard to tell from the press release. Bottom line: I'm going to believe this one someone displays a cert chain. Translated: GeoRoot is only available for internal use, and organizations must meet certain eligibility requirements, [...] compliance guidelines, and hardware security specifications. Organizations must maintain a list Certificate Revocation List (CRL) ^^ for all certificates issued by the company. But don't worry, Mozilla has a checklist for sub-CAs! https://wiki.mozilla.org/CA:SubordinateCA_checklist Home » CA:SubordinateCA_checklist Terminology The following terminology will be used in this wiki page regarding subordinate CAs. Third-Party: The subordinate CA is operated by a third party external to the root CA organization; and/or an external third party may directly cause the issuance of a certificate within the CA hierarchy. Third-party private (or enterprise) subordinate CAs: This is the case where a commercial CA has enterprise customers who want to operate their own CAs for internal purposes, e.g., to issue SSL server certificates to systems running intranet applications, to issue individual SSL client certificates for employees or contractors for use in authenticating to such applications, and so on. * These sub-CAs are not functioning as public CAs, so typical Mozilla users would not encounter certificates issued by these sub-CAs in s/would/should/ their normal activities. * For these sub-CAs we need assurance that they are not going to start functioning as public CAs. As Dan would say, security comes from this absence of the potential for this type of surprise. This is not security, this reliance. Currently the only assurances available for this case it to ensure that these third parties are required to follow practices that satisfy the Mozilla CA Certificate Policy, and that these third parties are under an acceptable audit regime. Promises, promises. o In Bug #394919 NSS is being updated to apply dNSName constraints to the CN, in addition to the SANs. o We plan to update our policy to require CAs to constrain third-party private (or enterprise) subordinate CAs so they can only issue certificates within a specified domain. See section 4.2.1.10 of RFC 5280. Someday. To be fair to Mozilla, at least they're the ones with an open policy about it. I didn't find such a policy for the other popular web clients (I may not have looked hard enough). - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Marsh Ray ma...@extendedsubset.com writes: Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public Root [...] SAN FRANCISCO, RSA CONFERENCE, Feb. 14 February of which year? If it's from this year then they're really late to the party, commercial CAs have been doing this for more than a decade. These things are huge money-earners for them, they start at around $50K per sub-CA cert and go from there, and because you have to do this to turn off the browser warnings, large numbers of companies do it. I don't know about actual figures, but from stories I've heard it wouldn't surprise me if many CAs made the majority of their income from selling padlocks [0] to companies rather than selling them to web sites. Or is GeoRoot some novel new thing that I'm not familiar with? Peter. [0] By selling padlocks I mean you give them money and people who come to your site get to see a padlock picture. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Ben Laurie b...@links.org writes: They appear to actually be selling sub-RA functionality, but very hard to tell from the press release. OK, so it does appear that people seem genuinely unaware of both the fact that this goes on, and the scale at which it happens. Here's how it works: 1. Your company or organisation is concerned about the fact that when people go to their site (even if it's an internal, company-only one), they get scary warnings. 2. Your IT people go to a commercial CA and say we would like to buy the ability to issue padlocks ourselves rather than having to buy them all off you. 3. The CA goes through an extensive consulting exercise (billed to the company), after which they sell the company a padlock-issuing license, also billed to the company. The company is expected to keep records for how many padlocks they issue, and pay the CA a further fee based on this. 4. Security is done via the honour system, the CA assumes the company won't do anything bad with their padlock-issuing capability (or at least I've never seen any evidence of a CA doing any checking apart from for the fact that they're not getting short-changed). This is why in the past I've repeatedly referred to unknown numbers of unknown private-label CAs, we have absolutely no idea how many of these private-label CAs are out there or who they are or who controls them, but they're probably in the tens, if not hundreds, of thousands, and many are little more than a Windows server on a corporate LAN somewhere (and I mean that literally, it was odd to sit in front of a Windows 2000 box built from spare parts located in what used to be some sort of supplies closet and think I can issue certs that chain to $famous_ca_name from this thing :-). Going through the process is like getting a BS 7799 FIPS 140 certification, you pay the company doing the work to get you through the process, and you keep paying them until eventually you pass. The only difference is that while I've heard of rare cases of companies failing BS 7799, I've never heard of anyone failing to get a padlock-issuing license. Are people really not aware of this? I thought it was common knowledge. If it isn't, I'll have to adapt a writeup I've done on it, which assumes that this is common knowledge. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On Wed, Nov 30, 2011 at 4:47 PM, Rose, Greg g...@qualcomm.com wrote: On 2011 Nov 30, at 16:44 , Adam Back wrote: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a few weeks ago. Yup. Boingo does this. Also, many employers. n ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 11/30/11, Rose, Greg g...@qualcomm.com wrote: On 2011 Nov 30, at 16:44 , Adam Back wrote: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a few weeks ago. How did you know there was a MITM if it gave out a valid cert? Thanks, Lee Greg. I saw Ondrej Mikle also mentions this concept in his referenced link from recent post: https://mail1.eff.org/pipermail/observatory/2011-November/000484.html - SSL inspection/MitM boxes sometimes show up before being configured (Blue Coat, SonicWall, Watchguard Fireware) How do they know you're going to put the cert in a blue coat box and inflict that only to your employees vs steal banking passwords and money of users in an airport? Do blue coat and other MitM proxies mentioned on this list recently actually support on the fly cert generation and putting a CA cert in there? I was presuming that to do so they user would have to self-sign a CA cert and upgrade their browsers on their corporate installs by adding their self-signed MitM cert to the trusted CA set in their standard image/install set. (Which is obnoxious but fair enough). But for a CA to intentionally issue an unrestricted sub-CA cert for installing in MitM boxes - that sounds outright lethal. How much do you trust the box security, the operators of the box. Do they sell such sub-CAs to Iran, Syria via shady intermediaries? What do these sub-CA certs cost? What do I have to say or sign to get one? Will they sell it to me to monitor my kids? Employees of a small startup? Adam On Wed, Nov 30, 2011 at 01:30:40PM -0600, Marsh Ray wrote: On 11/30/2011 12:01 PM, Ben Laurie wrote: On Wed, Nov 30, 2011 at 5:16 PM, Marsh Rayma...@extendedsubset.com wrote: Perhaps you define this category of publicly visible certs as certs which display without warnings on default-configured browsers when presented by the correct site. ... On the other hand, one could interpret this category of publicly visible certs as certs visible to the public, i.e., certs served by legitimate servers on routable IPs located via public DNS. But this interpretation would be much weaker (and I don't think that's what you mean). Although I rather like your first definition, this one seems closer to the truth: it may be that some sites which currently validate correctly in default-configured browsers would choose not to in our system. The certs I am worried about though are the certs that were issued in secret (e.g. Comodo and friends) and are never publicly visible until they are used in an attack. If the attack is sufficiently targeted, it may be the case that no one other than the victim ever sees the cert at all. In the event of a mass MitM attack (e.g. *.ir), the attacker would likely have free use of his previously-hidden cert for at least as long as the combined reporting, reaction, and revocation latency. It's not clear how this proposal is actually an improvement on the current system in this regard. On the other hand, if you *did* engage the CAs and get their buy-in, they could pledge to update the log promptly with every cert they issued. Specific CA certs could be configured with this flag in the browser's trusted store. This would allow a missing audit proof to be treated as a hard stop and would seem to be a more meaningful distinction among CAs than the current EV scheme. (The few CAs I've spoken were really grasping for ways with which the 'better' CAs could distinguish themselves in the industry.) Additionally, such a flag could be added to HSTS. Rather than pinning to a specific CA (I will only use this one CA ever), a site could pin itself to the use of a CA that promised to participate in the auditing. This would reduce some of the DoS potential inherent in CA pinning yet still allow browsers to catch that critical transition from provably logged cert to non-logged cert. But the proposal does nothing _directly_ to prevent a CA from issuing a cert, right? And since browsers aren't logging the certs as they find them, this doesn't inform the owner of the domain either. Instead it seems to be a hoped-for effect of default-configured browsers will raise hell if they are presented with a non-logged cert and CAs will feel compelled to go along with the audit logging. CAs do not have to go along with anything, the log will accept a cert from anyone - which obviously includes the owner of the cert. There would need to be a way for end-users to report new certs via their browser, much like they report browser crashes today. Wouldn't some users want it? I think it would be good to involve the users in this process as much as is practical. they'll have to put the certs they issue in the logs too, right? Someone
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Nathan Loofbourrow njl...@gmail.com writes: On Wed, Nov 30, 2011 at 4:47 PM, Rose, Greg g...@qualcomm.com wrote: On 2011 Nov 30, at 16:44 , Adam Back wrote: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a few weeks ago. Yup. Boingo does this. Also, many employers. Can someone send me a couple of certs (Amazon, Google, whatever) generated by one of these MITMs, specifically the full cert chain (Save as PKCS #7 in the cert dialog of most browsers)? I've got e.g. SonicWall ones where you have to trust the SonicWall CA cert, but presumably these are chained to a public CA so users don't get warnings, which means the proxies would have to be set up with more or less Comodogate-by-design CA certs. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
ianG i...@iang.org writes: Is this in anyway a cause for action in contract? Is this a caused for revocation? And given that you have to ask the MITM for the revocation information, how would you revoke such a cert? And that was Why blacklists suck for validity checks, reason #872 in a series of 10,000 or so. Returning you now to Max Geldray and Orchestra... Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
ianG i...@iang.org writes: On 1/12/11 15:10 PM, Peter Gutmann wrote: ianGi...@iang.org writes: Is this in anyway a cause for action in contract? Is this a caused for revocation? And given that you have to ask the MITM for the revocation information, how would you revoke such a cert? Wait! Mallory has delivered Alice a valid CA-signed-sub-CA-signed cert. That is the valid information, right? There was nothing wrong the cert that wasn't seen, it is the new one that is at fault. I assumed you were asking whether it was cause for revocation of the MITM CA. Since you have to go via the MITM to do the blacklist check, you're hosed. In any case though since you own the MITM CA all you need to do is leave out the authorityInfoAccess and the clients won't even try and check. Or make it a CRL, and many won't bother checking even if the AIA is present (that's a nice way to get a cheap CA cert for a year, buy it from a commercial CA, make sure the revocation is done via a CRL, say you changed your mind and want your money back, and you've got your own nearly-free CA cert for a year when nothing bothers checking the CRL, as users of such CA certs have discovered in the past :-). Those were reasons #528 and #309 in the series. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On Thu, Dec 1, 2011 at 5:32 AM, Rose, Greg g...@qualcomm.com wrote: On 2011 Nov 30, at 17:18 , Lee wrote: On 11/30/11, Rose, Greg g...@qualcomm.com wrote: On 2011 Nov 30, at 16:44 , Adam Back wrote: Are there really any CAs which issue sub-CA for deep packet inspection aka doing MitM and issue certs on the fly for everything going through them: gmail, hotmail, online banking etc. Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a few weeks ago. How did you know there was a MITM if it gave out a valid cert? I run a wonderful Firefox extension called Certificate Patrol. It keeps a local cache of certificates, and warns you if a certificate, CA, or public key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my stockbroker's web site, the warnings started to appear. Then it was just checking IP addresses and stuff. So ... let's see the cert(s), then! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote: I run a wonderful Firefox extension called Certificate Patrol. It keeps a local cache of certificates, and warns you if a certificate, CA, or public key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my stockbroker's web site, the warnings started to appear. Then it was just checking IP addresses and stuff. And I presume you didn't save the cert. Of course, we just need to have people look for these and then save them. Jon ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Jon Callas j...@callas.org writes: And I presume you didn't save the cert. Of course, we just need to have people look for these and then save them. Cert *chain*, not cert. Save as PKCS #7/Certificate Chain from the browser dialog. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
If only we at least used passwords to derive secret keys for authentication protocols that could do channel binding... Sure, that'd still be weak, but it would be much, much better than what we have now. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
On 2011-12-01 2:03 PM, ianG wrote: If a CA is issuing sub-CAs for the purpose of MITMing, is this a reason to reset the entire CA? Or is it ok to do MITMing under certain nice circumstances? It seems our CA system has come to resemble our audit system and our financial system. In very white rural areas, you will see stuff for sale on an honor system. Go in, help yourself, and put the money in the box. Where I now live, people often leave their house without locking the door behind them. That is how rednecks behave. As the community becomes more vibrant and diverse the high level of trust required for western institutions makes those institutions non viable. We have to reconstruct our institutions for third world trust levels and southern European trust levels. Institutions characteristic of Europe and the old North America are no longer capable of functioning, have not been capable of functioning for some time. On the other hand, a paranoid environment, where everything has to be locked, and every claim has to be provable, is good business for cryptographers. One can create institutions that will function well in such an environment, it is just trickier. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
