Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Philipp Gühring wrote: I had the feeling that Microsoft wants to abandon the usage of client certificates completely, and move the people to CardSpace instead. But how do you sign your emails with CardSpace? CardSpace only does the realtime authentication part of the market ... It's not rocket science. You have a public/private keypair. You can sign emails. For example, import your cardspace key into PGP. -- 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 [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Thierry Moreau [EMAIL PROTECTED] writes: At first, it seems neat. But then, looking at how it works in practice: the client receives an e-mail notification soliciting him to click on a HTML link and then enroll for a security certificate, the client is solicited exactly like a phishing criminal would do, Correction, exactly like phishing criminals are actively doing right now (hat tip to Don Jackson of SecureWorks who's investigated and documented this practice). Given the almost complete failure of client certs in the marketplace, I found it most amusing that the current active users of client certs are phishers. It reminded me of spammers and SPF. Title: Sender driven certification enrollment system Document Type and Number: United States Patent 6651166 Link to this page: http://www.freepatentsonline.com/6651166.html Filing Date: 04/09/1998 Publication Date: 11/18/2003 Thus postdating Microsoft's CertEnroll/Certenr3/Xenroll ActiveX control by several years. The only difference here is that the user generates the cert directly rather than involving a CA. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Leichter, Jerry wrote: While trying to find something else, I came across the following reference: Title: Sender driven certification enrollment system Document Type and Number: United States Patent 6651166 Link to this page: http://www.freepatentsonline.com/6651166.html Abstract: A sender driven certificate enrollment system and methods of its use are provided, in which a sender controls the generation of a digital certificate that is used to encrypt and send a document to a recipient in a secure manner. The sender compares previously stored recipient information to gathered information from the recipient. If the information matches, the sender transfers key generation software to the recipient, which produces the digital certificate, comprising a public and private key pair. The sender can then use the public key to encrypt and send the document to the recipient, wherein the recipient can use the matching private key to decrypt the document. Some feedback on the above security certificate issuance process. At first, it seems neat. But then, looking at how it works in practice: the client receives an e-mail notification soliciting him to click on a HTML link and then enroll for a security certificate, the client is solicited exactly like a phishing criminal would do, and a java software utility downloaded from the web should not be allowed to modify security-critical parameters on the local machine. According to my records, this issuance process is nonetheless representative of research directions for user enrollment, i.e. there aren't too many other documented processes in this area. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
On Feb 11, 2008, at 8:28 AM, Philipp Gühring wrote: I had the feeling that Microsoft wants to abandon the usage of client certificates completely, and move the people to CardSpace instead. But how do you sign your emails with CardSpace? CardSpace only does the realtime authentication part of the market ... We (Morgan Stanley) were able to pressure them into a rapid fix, and they have committed to delivering it in SP1. Keep your fingers crossed. If anyone needs more information how to upgrade your Web-based CA for IE7: http://wiki.cacert.org/wiki/IE7VistaSource Step (2), On Vista you have to add this website to the list of trusted sites in the internet-settings. can be quite unpalatable. Depending on your customers' situations, an alternative might be more palatable: Generate the key and deliver a PKCS#12. This depends on whether you believe in the non-repudiation fairy or not -- or more accurately, whether you're already assuming the repudiation risk. -wps - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this? You don't have to imagine this. It is exactly how Infocard (the generic name of the technology of which Microsoft's CardSpace is one implementation of one component) works in its most common mode (the personal or self-issued card). It has lots of other benefits as well even in this mode (user-managed attributes, graphical UI) as well as other modes to support identity providers (managed cards). Lest you think that this is Microsoft-only, be assured that there is a large community building implementations for many other platforms and systems. OSIS (http://osis.idcommons.net/) is the prime venue for people to work on interoperability across the spectrum of implementations. There's a big interop event coming up at the RSA conference in April. If you'd like to help make your scenario a pervasive reality, check it out. - RL Bob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Is anyone aware of any third-party usability studies on CardSpace, OpenID, ...?). I'm not. It would be a good opportunity for security usability researchers to contribute though. [0] I'm not sure whether putting CardSpace and Liberty in such close proximity in the above line was a good idea. If your monitor starts smoking due to the friction generated, please cutpaste one of the two elsewhere. Actually lots of Liberty and WS/Infocard/etc people are working on interop scenarios, see: http://projectconcordia.org/index.php/Main_Page - RL Bob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Hi, Microsoft broke this in IE7... It is no longer possible to generate and enroll a client cert from a CA not on the trusted root list. So private label CAs can no longer enroll client certs. We have requested a fix, so this may come in the future, but the damage is already done... Also the IE7 browser APIs for this are completely different and rather minimally documented. The interfaces are not portable between browsers, ... It's a mess. I can fully confirm this. Microsoft claimed that they had to rewrite the API to make it more secure, but I only found one small security-relevant weakness that they fixed, the others are still there. (And even that fix wouldn´t have justified a rewrite of the API for websites. They could have kept the frontend-API compatible in my opinion.) I had the feeling that Microsoft wants to abandon the usage of client certificates completely, and move the people to CardSpace instead. But how do you sign your emails with CardSpace? CardSpace only does the realtime authentication part of the market ... If anyone needs more information how to upgrade your Web-based CA for IE7: http://wiki.cacert.org/wiki/IE7VistaSource Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
| By the way, it seems like one thing that might help with client certs | is if they were treated a bit like cookies. Today, a website can set | a cookie in your browser, and that cookie will be returned every time | you later visit that website. This all happens automatically. Imagine | if a website could instruct your browser to transparently generate a | public/private keypair for use with that website only and send the | public key to that website. Then, any time that the user returns to | that website, the browser would automatically use that private key to | authenticate itself. For instance, boa.com might instruct my browser | to create one private key for use with *.boa.com; later, | citibank.com could instruct my browser to create a private key for | use with *.citibank.com. By associating the private key with a specific | DNS domain (just as cookies are), this means that the privacy | implications of client authentication would be comparable to the | privacy implications of cookies. Also, in this scheme, there wouldn't | be any need to have your public key signed by a CA; the site only needs | to know your public key (e.g., your browser could send self-signed | certs), which eliminates the dependence upon the third-party CAs. | Any thoughts on this? While trying to find something else, I came across the following reference: Title: Sender driven certification enrollment system Document Type and Number: United States Patent 6651166 Link to this page: http://www.freepatentsonline.com/6651166.html Abstract: A sender driven certificate enrollment system and methods of its use are provided, in which a sender controls the generation of a digital certificate that is used to encrypt and send a document to a recipient in a secure manner. The sender compares previously stored recipient information to gathered information from the recipient. If the information matches, the sender transfers key generation software to the recipient, which produces the digital certificate, comprising a public and private key pair. The sender can then use the public key to encrypt and send the document to the recipient, wherein the recipient can use the matching private key to decrypt the document. This was work done a Xerox. I was trying to find a different report at Xerox in response to Peter Gutmann's comment that certificate aren't used because they are impractical/unusable. Parc has done some wonderful work on deal with those problems. See: http://www.parc.com/research/projects/usablesecurity/wireless.html Not Internet scale, but in an enterprise, it should work. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
re: http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL so lots of the AADS http://www.garlic.com/~lynn/x959.html#aads scenarios are that every place a password might appear, have a public key instead. for various of the cookie authentication operations ... also think kerberos tickets. recent reference http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service part of the scenario for cookie/ticket encryption ... involving servers, is brute force attack on the server secret key. the cookie instead of all encrypted data ... has some sort of client registration value ... analogous to an account number or userid. the cookie caries the registration value followed by the server encrypted data. the encryption part uses a derived key ... formed by combination of the server's secret key and the client's registration value. these derived key scenarios are also found in transit system operation (both magstripe and memory chip) as well as financial transactions. the issue then is initial registration ... the part where the user chooses their userid (and/or the client registration value is otherwise selected) and supplies a password (but in this case a public key). m'soft and others have been using CAPTCHA to weed-out the non-humans, but this has come under attacks. reference to recent news items http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's CAPTCHA the ticket/cookie carries the clients public key (and whatever other characteristics) ... which then can be used by the server(s) to perform dynamic authentication (digital signing of some server supplied, random data, countermeasure to replay attacks). this is in lieu of server having to maintain the client account record ... ala a RADIUS scenario where public key has been registered in lieu of a password (some sort of online access to RADIUS account records). various RADIUS public key in lieu of password postings: http://www.garlic.com/~lynn/subpubkey.html#radius the ticket/cookie scenario (with derived key encryption) is cross between dynamic server-side account record data (say RADIUS repository) and stale, static digital certificate scenario. as in the transit gate operation, the ticket/cookie could also be retrieved, decrypted, updated, re-encrypted, and returned as part of the operation. initial server hand-shakes can include server sending some random challenge data. The client returns the digital signature and their previously obtained cookie. in the straight RADIUS public key handshake scenario, just the digital signature and client userid/account-number is returned since the rest of the cookie/ticket equivalent info is online in the RADIUS account repository. The straight RADIUS scenario would be to combine the server-side random challenge data and combine it with the client registration value (account number, userid) and whatever else the client-side digital signing requires ... and return the userid/account-number any other data and digital signature (i.e. server-side has to be able to reconstruct what the client actually digitally signed as part of verifying the digital signature). In the straight RADIUS scenario, the public key (and any associated permissions, authorization, etc) is obtained from the RADIUS repository. In cookie/ticket scenario, it is obtained from the cookie/ticket appended to the message. The business process still has the initial registration phase ... where the original cookie is created (or in the RADIUS scenario, where the userid definitiion is initially created) and the public key is supplied (in lieu of a password). This is also effectively the original certificateless pk-init scenario for kerberos (aka public key in lieu of password) http://www.garlic.com/~lynn/subpubkey.html#kerberos The cookie scenario is standard client/server ... attempting to eliminate the server having to retain the account record on behalf of every client (as in either the RADIUS and/or KERBEROS scenario). Encrypting of the cookie data is standard ... although transit systems and financial transactions have gone to derived key for the situation ... as countermeasure to brute force attack on the infrastructure secret key. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fixing SSL (was Re: Dutch Transport Card Broken)
Tim Dierks writes: (there are totally different reasons that client certs aren't being widely adopted, but that's beside the point). I'd be interested in hearing your take on why SSL client certs aren't widely adopted. It seems like they could potentially help with the phishing problem (at least, the problem of theft of web authenticators -- it obviously won't help with theft of SSNs). If users don't know the authentication secret, they can't reveal it. The nice thing about using client certs instead of passwords is that users don't know the private key -- only the browser knows the secret key. The standard concerns I've heard are: (a) SSL client supports aren't supported very well by some browsers; (b) this doesn't handle the mobility problem, where the user wants to log in from multiple different browsers. So you'd need a different mechanism for initially registering the user's browser. By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. Today, a website can set a cookie in your browser, and that cookie will be returned every time you later visit that website. This all happens automatically. Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
David Wagner wrote: I'd be interested in hearing your take on why SSL client certs aren't widely adopted. It seems like they could potentially help with the phishing problem (at least, the problem of theft of web authenticators -- it obviously won't help with theft of SSNs). If users don't know the authentication secret, they can't reveal it. The nice thing about using client certs instead of passwords is that users don't know the private key -- only the browser knows the secret key. The standard concerns I've heard are: (a) SSL client supports aren't supported very well by some browsers; (b) this doesn't handle the mobility problem, where the user wants to log in from multiple different browsers. So you'd need a different mechanism for initially registering the user's browser. By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. Today, a website can set a cookie in your browser, and that cookie will be returned every time you later visit that website. This all happens automatically. Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this? in AADS http://www.garlic.com/~lynn/x959.html#aads and certificateless public key http://www.garlic.com/~lynn/subpubkey.html#certless we referred to the scenario as person-centric ... as a contrast to institutional-centric oriented implementations. past posts in this thread: http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken) http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken) http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch Transport Card Broken) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
On 2/9/08, David Wagner [EMAIL PROTECTED] wrote: By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. I don't see how this helps with phishing. Phishers will just go after the password or other secrets used to authenticate a new system or a system that has lost its cert. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote: By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. Today, a website can set a cookie in your browser, and that cookie will be returned every time you later visit that website. This all happens automatically. Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. Microsoft broke this in IE7... It is no longer possible to generate and enroll a client cert from a CA not on the trusted root list. So private label CAs can no longer enroll client certs. We have requested a fix, so this may come in the future, but the damage is already done... Also the IE7 browser APIs for this are completely different and rather minimally documented. The interfaces are not portable between browsers, ... It's a mess. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
They can't be as anonymous as cash if the party being dealt with can be identified. And the party can be identified if the transaction is online, real-time. Even if other clues are erased, there's still traffic analysis in this case. If I show up at a store and pay cash for something every week, they can still do traffic analysis on me (oh him, he's a regular customer) unless I go out of my way to obscure my routine like asking other people to buy stuff for me. It's not clear to me what the object of this argument is. Yes, the harder you work, the more difficult you can make it for other people to tie your transactions to you. This shouldn't be news to anyone. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
a recent reference Research unmasks anonymity networks http://www.techworld.com/security/news/index.cfm?newsID=11295 Research unmasks anonymity networks http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html Research unmasks anonymity networks http://www.arnnet.com.au/index.php/id;1270745171;fp;4194304;fpid;1 Paper Outlines Methods for Beating Anonymity Technology http://www.darkreading.com/document.asp?doc_id=144606 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Anne Lynn Wheeler [EMAIL PROTECTED] write: one of my favorite exchanges from the mid-90s was somebody claiming that adding digital certificates to the electronic payment transaction infrastructure would bring it into the modern age. my response was that it actually would regress the infrastructure at least a couple decades to the time when online, real-time transactions weren't being done. The online, real-time transaction provides much higher quality and useful information than a stale, static digital certificate (with an offline paradigm from before modern communication). Having an available repository about the party being dealt with ... including things like timely, aggregated information (recent transactions) is significantly mover valuable than the stale, static digital certificate environment (the only thing that it has going for it, is it is better than nothing in the oldtime offline environment). [...] EU had also made a statement in the mid-90s that electronic retail payments should be as anonymous as cash. They can't be as anonymous as cash if the party being dealt with can be identified. And the party can be identified if the transaction is online, real-time. Even if other clues are erased, there's still traffic analysis in this case. What the offline paradigm has going for it is the possibility of true, untraceable anonymity through the use of anonymizing remailers and related technologies. -- StealthMonger [EMAIL PROTECTED] -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. http://stealthsuite.afflictions.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
StealthMonger wrote: They can't be as anonymous as cash if the party being dealt with can be identified. And the party can be identified if the transaction is online, real-time. Even if other clues are erased, there's still traffic analysis in this case. What the offline paradigm has going for it is the possibility of true, untraceable anonymity through the use of anonymizing remailers and related technologies. most people who heard the statement, understood that. i think that possibly 2nd level detail was that they didn't want PII easily associated by casual merchant. Initial response was to remove name from payment cards magstripes. This also precluded merchants from requesting other forms of identification to see if the names matched the name on the payment card. The implication being that the payment infrastructure would have to come up with other mechanisms to improve the infrastructure integrity. The offline payment paradigms ... while touting true anonymity were actually primarily justified based on other factors. We had been asked to design and cost the dataprocessing supporting US deployments of some of the offline products (that were being used in Europe). Along the way, we did some business process and revenue analysis and realized that the primary motivation behind these system deployments was the float. About the same time that there was the EU about the privacy of electronic retail payments ... there was also a statement by the EU (and some of the country central banks) that the offline products would be allowed to keep the float for a short grace period to help in the funding of the infrastructure deployment ... but after the grace period ... the operators would have to start paying interest on the balance held in the offline instruments (eliminating float from the equation). After that, much of the interest in the offline deployments drifted away. In that time frame we had also done design, implementation and deployment of a payment transaction infrastructure supporting target marketing ... recent reference http://www.garlic.com/~lynn/2008c.html#27 Diversity support was for a small pilot of 60mil accounts and 1.5million transaction/day ... but capable of scaling up to 20-30 times that amount. There was significant attention paid to privacy issues and it was subject to quarterly auditing by some dozen or so privacy organizations. there had to be a large amount of sensitive treatment of the information along the lines of what HIPAA specifies for health information. aka: anonymized Previously identifiable data that have been deidentified and for which a code or other link no longer exists. An investigator would not be able to link anonymized information back to a specific individual. [HIPAA] (see also anonymous, coded, directly identifiable, indirectly identifiable) as part of co-authoring x9.99 financial privacy standard, one of the things we created was a privacy merged glossory and taxonomy ... including GLBA, HIPAA, and EU-DPD references some notes: http://www.garlic.com/~lynn/index.html#glosnote in our work on x9.59 financial transaction standard http://www.garlic.com/~lynn/x959.html#x959 we made the statement that it was privacy agnostic ... since the transactions were tied to accounts ... but then whether or not the accounts were tied to individuals was outside the x9.59 standard http://www.garlic.com/~lynn/subpubkey.html#x959 As a total aside ... as part of the Digicash liquidation, we were brought in to evaluate the patent portfolio. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
(as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. People don't use it because the workload of getting signed up is vastly beyond their skillset, and the user experience using the things is pretty bad too. And there are hundreds of internal systems I heard of that are using client certificates in reality every day. There's always a few people using a technology. It's certainly a nonplayer out there. Probably more servers out there authing with Digest, honestly. Validated email addresses for spamming. Spear-phishing perhaps, ... There are CA´s on this planet that put things like social security numbers into certificates. Who? Seriously, that's pretty significant, I'd like to know who does this. Where does the SSL specification say that certificates shouldn´t contain sensitive information? I am missing that detail in the security consideration section of the RFC. The word public in Public Key isn't exactly subtle. Do we have any more ideas how we can get this flaw fixed before it starts hurting too much? Make it really easy to use some future version of SSL client certs, and quietly add the property you seek. Ease of use drives technology adoption; making the tech actually work is astonishingly secondary. Heh, you asked :) We have an issue here. And the issue isn´t going to go away, until we deprecate SSL/TLS, or it gets solved. To be clear, we'd *have* an issue, if any serious number of people used SSL client certs. I think you have a point that if SSL client certs become very popular going forward, then every website you go to will quietly grab your identity through their ad banners. * We fix SSL Does anyone have a solution for SSL/TLS available that we could propose on the TLS list? If not: Can anyone with enough protocol design experience please develop it? What solution could there be? You're actually going to SSL to the banner ad network, and you're going to give them your client cert. * We deprecate SSL for client certificate authentication. We write in the RFC that people MUST NOT use SSL for client authentication. (Perhaps we get away by pretending that client certificates accidently slipped into the specification.) People by in large do not use SSL client cert authentication. This is problematic, as there's some very nice cryptographic aspects of the system. * We switch from TLS to hmmm ... perhaps SSH, which has fixed the problem already. Hmm, there we would have to write all the glue RFCs like HTTP over SSH again ... I used to code for SSH. SSL is an entire top-to-bottom stack, replete with a deep PKI infrastructure. SSH? Tunneling transport, barely even librarized. Try to send a DVD iso image (4GB) over a SSL or SSH encrypted link with bit errors every 1 bits with a client software like scp that cannot resume downloads. I gave up after 5 tries that all broke down in average after 1 GB. (In that case it was a hardware (bad cable) initiated denial of service attack ;-) The problem here isn't checksums. SSH is notoriously buggy when packets are dropped. I think there are certain windows in which OpenSSH assumes it will get a response. If it doesn't, it just dies. So, outages more than a few hundred milliseconds have a small percentage chance of causing the session to permanently stall. Corrupted MAC on input -- this is a decent sign of corruption at the app layer. Did you really try this with OpenSSL? I've had much better luck there. If the link layer gives you 1/256, and the TCP layer gives you 1/65536, and the SSL layer demands 0/16777216, then end up with 1/16777216 too much. Actually, 256*65536 = 1677216 :) In actuality, you have both IP and TCP checksums. So you get 8 bits from link, 16 bits from IP, and 16 bits from TCP. A random corrupt packet has about 2^40 odds of getting through. Of course, one real problem is that the checksum algorithms don't exactly distribute noise randomly, and noise is not random. Still, corruption doesn't start being a problem until you get some pretty serious amounts of transfer. (Interestingly, I've been looking at IPsec lately, not for encryption, but for better checksumming.) Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Eric Rescorla wrote: (as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. No, if it were *convenient* people would use it. I know of absolutely zero evidence (nor have you presented any) that people choose not to use certs because of this kind of privacy issue--but I know of plenty that they find getting certs way too inconvenient. In a CA I have something to do with, I'm observing a site that just started experimenting with client certs (100 users, will reach 1000, maybe more). When we discovered that the certificate includes PII (personally identifying information) and the website stores additional PII, the service was directed to drop all additional PII, and some thought was put into the in-cert PII. Current view is that the service must engage the user in a contract to accept the storing of that in-cert PII, otherwise it must not store the info in the cert (which means no identity, no persistence, and no point to the client certs). Writing contracts and securing agreement of course is a barrier, a burden. If this were a general requirement, then this would be enough (imho) to not recommend client certs, because contracts need lawyers, they cost real money, they don't solve the problem, and not recommending them is likewise unacceptable. (Then, as you say, there are convenience issues.) This is an experiment to force client certs to be used, so they are plugging on. It's a CA so it is trying to prove that there is value in these things. So... there are two slight variations that could be employed. Firstly, all data placed in the cert could be declared public in advance, and then no contract is required to use it in a context that is compatible with public data. That is, the question of the contract is pushed to the CA/CPS. (You mentioned that the premise is that it is all public data...) Another variation is to switch to username + password, of course, in which case the username is freely given and expected to be stored (certs being more or less invisible to users, so we can presume no such). (definately open to other ideas...) The PII equation is particularly daunting, echoing Lynn's early '90s experiences. I am told (but haven't really verified) that the certificate serial number is PII and therefore falls under the full weight of privacy law regs ... this may sound ludicrous, but privacy and security are different fields with different logics. If that is true, the liability is far too high for something that should be private, but is already public by dint of its exposure in certificates. Privacy liabilities are sky-high in some places, and not only that, they are incalculable, unknowable, and vary with the person you are talking to. So a superficial conclusion would be don't use client certificates because of the privacy issues although the issues are somewhat more complex than PII revealed in SSL key exchange. As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having fun observing them trying to prove that client certs are worth any amount of effort. iang PS: normal disclosures of interest + conflicts, included. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Ian G wrote: The PII equation is particularly daunting, echoing Lynn's early '90s experiences. I am told (but haven't really verified) that the certificate serial number is PII and therefore falls under the full weight of privacy law regs ... this may sound ludicrous, but privacy and security are different fields with different logics. If that is true, the liability is far too high for something that should be private, but is already public by dint of its exposure in certificates. Privacy liabilities are sky-high in some places, and not only that, they are incalculable, unknowable, and vary with the person you are talking to. So a superficial conclusion would be don't use client certificates because of the privacy issues although the issues are somewhat more complex than PII revealed in SSL key exchange. As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having fun observing them trying to prove that client certs are worth any amount of effort. the problem that digital certificates were suppose to address was first time communication between strangers ... the electronic analogy of the letters of credit/introduction from sailing ship days. this harks back to the offline email days of the early 80s ... dial-up electronic post-office, exchange email, hangup, and now authenticate first-time email from total stranger. the design point assumptions are invalidated if the relying party has their own repository of information about the party being dealt with (and therefor can included that party's public key) and/or has online, timely electronic access to such information. one of my favorite exchanges from the mid-90s was somebody claiming that adding digital certificates to the electronic payment transaction infrastructure would bring it into the modern age. my response was that it actually would regress the infrastructure at least a couple decades to the time when online, real-time transactions weren't being done. The online, real-time transaction provides much higher quality and useful information than a stale, static digital certificate (with an offline paradigm from before modern communication). Having an available repository about the party being dealt with ... including things like timely, aggregated information (recent transactions) is significantly mover valuable than the stale, static digital certificate environment (the only thing that it has going for it, is it is better than nothing in the oldtime offline environment). misc. past posts referencing certificate-less public key operation http://www.garlic.com/~lynn/subpubkey.html#certless for some real topic drift ... i've mentioned x9.59 financial standard protocol that can use digital signatures for authentication w/o requiring digital certificates http://www.garlic.com/~lynn/x959.html#x959 part of the issue included that digital certificates (even relying party only digital certificates) can add a factor of one hundred times payload bloat to a typical payment transaction http://www.garlic.com/~lynn/subpubkey.html#bloat however, we were also got involved in co-authoring the x9.99 privacy standard ... as part of that we had to look at a number of things, HIPAA, GLBA ... as well as EU-DPD. as part of that we had also done a privacy merged taxonomy and glossary ... some notes http://www.garlic.com/~lynn/index.html#glosnote EU had also made a statement in the mid-90s that electronic retail payments should be as anonymous as cash. The dominant use of SSL in the world today is electronic commerce between a consumer and a merchant. Passing a client certificate (with PII information) within an encrypted SSL channel to a merchant ... still exposes the information to the merchant ... also violating making purchases as anonymous as cash. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Philipp Gühring wrote: I once implemented SSL over GSM data channel (without PPP and without TCP), and discovered that SSL needs better integrity protection than raw GSM delivers. (I am quite sure that´s why people normally run PPP over GSM channels ...) SSH has the same problems. It also assumes an active attack in case of integrity problems of the lower layer, and terminates the connection. TBH I can't see the problem - the unix philosophy of doing one thing well, and chaining simple tools to make complex ones, works well here. we have: TCP - well understood, has crude integrity and reliability checks built in, works reasonably well at converting a bunch of packets leaving and arriving via your network connection into something vaguely like a stream point-to-point connection. Provided by every ISP across the planet, problems at this level can be handed off to experienced network engineers who will at least understand the problem. SSL - Cludge thrown together by a browser manufacturer, probably to create a market for a bunch of companies who generated two prime numbers and now sell the answers to simple math queries involving the numbers. However, works reasonably well, has some crude authentication of the server built in (via the aformentioned bunch of companies) which at least limits potential hackers to those whose money the bunch of companies will accept ;) Again, works well in its domain, but requires a reasonably reliable channel to talk over, and a message to carry. Effectively turns an unencrypted channel into an encrypted one, Would work as well over a serial link as a tcp link (modulo the domain name check in the cert) HTTP - pretty basic file transfer protocol, with limited scope for negotiation, but designed largely to move text files from a server to a client. requires transport, can use tcp, ssl-over-tcp, serial, whatever your server will listen on and your client request on. add them together and you get HTTPS. leave out the SSL, and you get HTTP as-normally-spoke, so the SSL and HTTP are pretty much drop in modules. you could define HTTPG (HTTP over a security protocol other than SSL) and if a browser could support it, both TCP and HTTP would still be happy. you could also define HTTPS-over-adis-lamp and provided the operators were sufficiently accurate, securely download your web page from a server on a nearby hilltop after dark by replacing the TCP layer :) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Eric Rescorla wrote: Huh? What are you claiming the problem with sending client certificates in plaintext is (as if anyone uses client certificates anyway)? Well that is one problem - no one uses them, and no one should use them, while PKI was designed under the assumption that everyone would be using them. Another problem is that in practice the system merely ensures you are getting the purported domain name. Since we are overwhelmed by a multitude of irrelevant and confusing domain names, this is not much help. Further, I frequently get the warning that the certificate does not agree with the domain name when I know well that I am communicating with the intended entity - frequent misconfiguration results in false warnings, which I am thus trained to ignore, rendering the system entirely useless. Since we rely on passwords, social security numbers, and so forth, shared secrets, people are trained to give away secrets to purported authority, which creates the phishing hazard. We need to fix both problems. Of course, if the phishing hazard was fixed, we would still have the malware hazard, but we now know how to fix the malware hazard. We should fix both problems, rather than using one as an excuse for not fixing the other. We need to fix the network assuming the node is going to be made safe, and fix the node assuming the network is going to be made safe. Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? Eric Rescorla wrote: This gets discussed on the TLS mailing list occasionally, but the arguments for making this change aren't very convincing. If you have an actual credible security argument you should post it to [EMAIL PROTECTED] I don't think that is a useful discussion forum. The IETF is moribund, paralyzed and increasingly irrelevant. If the internet is to be fixed, the fixes have to bypass the IETF. When one has a large group, group dynamics can make the large group a little bit smarter than its smartest members, but more commonly, make it a lot dumber than its dumbest members. If the IETF was capable of handling, or even noticing, the crisis that we in then we would not be in this crisis. To fix the phishing problem, we need to cryptographically secure relationships, rather than attempting to cryptographically secure true names, and to greatly reduce reliance on revealing shared secrets. It should be unusual and disturbing to reveal shared secrets, rather than routine, and it should only be done with humans, not machines. 1. As with Skype to Skype IM, the fact that you can receive a message from what purports to be an entity with which you have a relationship, should be compelling evidence that it really is that entity, the entity to which you have given a petname on your contacts list. Thus phishing is hard to initiate. As with Skype, what we seek to secure is petnames, not true names. We want to secure the bookmark list, and the list that comes up in a Google search. We want to secure that when you click on a the top entry of the Google list, you are contacting the intended entity. 2. As with Skype to Skype IM, this should be symmetric. If you respond to a message from your bank, or initiate a message to your bank, you should not have to reveal some shared secrets to prove an existing relationship before getting on with your task. Thus phishing should fail to catch any phish. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Hi, Huh? What are you claiming the problem with sending client certificates in plaintext is * It´s a privacy problem * It´s a security problem for people with a security policy that requires the their identities to be kept secret, and only to be used to authenticate to the particular server they need * It´s an availability problem for people that need high-security authentication mechanisms, combined with high-privacy demands * It´s a identity theft problem in case the certificate contains personal data that can be used for identity theft Quoted from Lynns email: i.e. the x.509 identity digital certificates from the early 90s, were becoming more and more overloaded with personal information ... and by the mid-90s, lots of institutions were starting to realize all that personal information represented significant privacy and liability issues ... and the RPO digital certificates were born. * It´s a liability issue (Lynn, can you go into more details here? On the other hand, I would say it´s self-explaining ...) (as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. If you want a public example of client certificate usage: https://secure.cacert.org/ (You need a (free) client certificate from www.CAcert.org to be able to access this page) There are ISPs out there who provide internet access based on client certificates, authenticated in HTTPS sessions Creative Commons is running a registry for digital works, based on authors client certificate authentication: http://www.registeredcommons.org/ The Austrian governmental inhabitant register is using client certificates for about 10,000 users all around Austria since 2001. (If I remember the details correctly) http://zmr.bmi.gv.at/pages/home.htm And there are hundreds of internal systems I heard of that are using client certificates in reality every day. That the phisher gets to see the client's identity? Validated email addresses for spamming. Spear-phishing perhaps, ... So what? Why doesn´t SSH leak the client identity in plaintext? The problem isn´t a key-agreement problem. The problem is a client-authentication problem. It doesn't let them impersonate the client to anyone. It does let them impersonate the client to anyone who doesn´t care about the public key. (There are applications that just use the DN+Issuer information that they normally extract out of the certificates, ...) But impersonation is just one threat out of the huge SSL/TLS threat-model. Certificates shouldn't contain sensitive information anyway. There are CA´s on this planet that put things like social security numbers into certificates. (I guess those CA´s would say that SSL shouldn´t leak certificates in plaintext anyway.) Shovling around responsibility won´t help us. Let´s fix the problems. (Yes, we are already trying to get those CA´s to stop doing that ... but it´s a bit like asking credit card companies to not print those sensitive creditcard numbers on those credit cards ...) And there are a lot of people who would be interested to use certificates for more applications than pure identity. (which aren´t necessarily sensitive, but they are personal related data) Where does the SSL specification say that certificates shouldn´t contain sensitive information? I am missing that detail in the security consideration section of the RFC. There is a market demand for using sensitive information in certificates, dating back to the mid 90's (according to Lynn), and showing itself in various forms like Stefan Brands credentials, Attribute Certificates, and even the OACerts by Jiangtao Li and Ninghui Li. I have been talking to many people about client certificates and client authentication, and a lot of them are interested in using client certificates for authentication, and also to add other attributes to the certificates. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... No it isn't more secure. Using username+password inside HTTPS does not leak the client´s identity in cleartext on the line. (If I am wrong and HTTPS leaks usernames sent as HTTP Forms or with HTTP Basic Authentication, please tell me) Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? Do we have any more ideas how we can get this flaw fixed before it starts hurting too much? This gets discussed on the TLS mailing list occasionally, but the arguments for making this change aren't very convincing. Yes, there are regularly people popping up there that need it, but they always get ignored there, it seems. I think we have the boiling frog problem here. (Frog not recognizing
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Philipp Gühring wrote: Hi, SSL key distribution and management is horribly broken, with the result that everyone winds up using plaintext when they should not. Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) If I recall correctly, SSL was designed chronologically after ISO OSI Network-Layer Security Protocol (yes, the official WAN was actually X.25 at one point) or Transport Layer Security Protocol, both in their connection-oriented flavor, which used ideas originating from DecNET designs (researcher names Tardo, Alagappan; I once had a patent number in this thread of protocol engineering, but I lost it). Anyway, the key point in these visionary ideas is that the D-H exchange occurs *before* the exchange of security certificates. This provided the traffic-flow confidentiality that becomes desirable to protect privacy these days. So, you got your fix with OSI NLSP or TLSP, you just have to overcome the *power of the installed base*! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
At Thu, 31 Jan 2008 03:04:00 +0100, Philipp Gühring wrote: Hi, Huh? What are you claiming the problem with sending client certificates in plaintext is * It´s a privacy problem * It´s a security problem for people with a security policy that requires the their identities to be kept secret, and only to be used to authenticate to the particular server they need * It´s an availability problem for people that need high-security authentication mechanisms, combined with high-privacy demands * It´s a identity theft problem in case the certificate contains personal data that can be used for identity theft I don't find this at all convincing. There are a variety of different threat vectors here: 1. Phishing. 2. Pharming (DNS spoofing). 3. Passive attacks. In the case of phishing, the fact that the client sends its certificates in the clear is totally irrelevant, since the client would simply send its identity encrypted under the server's certificate. The only fix for this alleged privacy leak in the phishing context is for the client to refuse to deliver his certificate to anyone but people who present valid certs that he otherwise trusts. Now, this is potentially an attack if the attacker is passive but on-path, either via pharming or via subverting some router, but I'm unaware of any evidence that this is used as a certificate disclosure attack vector. (as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. No, if it were *convenient* people would use it. I know of absolutely zero evidence (nor have you presented any) that people choose not to use certs because of this kind of privacy issue--but I know of plenty that they find getting certs way too inconvenient. That the phisher gets to see the client's identity? Validated email addresses for spamming. Spear-phishing perhaps, ... Validated email addresses are not exactly hard to obtain. It doesn't let them impersonate the client to anyone. It does let them impersonate the client to anyone who doesn´t care about the public key. (There are applications that just use the DN+Issuer information that they normally extract out of the certificates, ...) If those applications do not force the client to do proof of possession of the private key, then they are fatally broken. It's not our job to fix them. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... No it isn't more secure. Using username+password inside HTTPS does not leak the client´s identity in cleartext on the line. (If I am wrong and HTTPS leaks usernames sent as HTTP Forms or with HTTP Basic Authentication, please tell me) No, it just leaks the password to the phishing server. Yeah, that's totally a lot better. This gets discussed on the TLS mailing list occasionally, but the arguments for making this change aren't very convincing. Yes, there are regularly people popping up there that need it, but they always get ignored there, it seems. Because the arguments they present are handwavy and unconvincing, just like yours. If you have an actual credible security argument you should post it to [EMAIL PROTECTED] Do you think the the security arguments I summed up above qualify on the tls list? It's an open list. Feel free to make these arguments. Should I go into more detail? Present practical examples? I would certainly find practical examples more convincing than the ones you've presented. I see several possible options: * We fix SSL Does anyone have a solution for SSL/TLS available that we could propose on the TLS list? If not: Can anyone with enough protocol design experience please develop it? There's already a solution: double handshake. You do an ordinary handshake with server auth only and then you do a second handshake with client auth. This hides the certificate perfectly well. Yes, you have to do two private key ops on the server, but if this issue is as important as you say, this is a tradeoff you should be happy to make. I've pointed this out on the TLS mailing list a number of times, but maybe you missed it. * We change the rules of the market, and tell the people that they MUST NOT ask for additional data in their certificates anymore Fundamentally, this *is* the fix. Even if SSL guaranteeed that nobody but the person you were handshaking with got the certificate, this is still incredibly brittle because any random server can ask you for your cert and users can't be trusted not to hand them over. The basic premise of certs is that they're public info. If you want to carry private data around in them then you should encrypt that data. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t
RE: Fixing SSL (was Re: Dutch Transport Card Broken)
To add to the examples Philipp has mentioned, I've been closely involved in the design and implementation of a number of projects for the Spanish government using SSL + client certificates; indeed, the new Spanish ID card includes two certificates, one for authentication and the other for digital signature. There are some examples of services using SSL+client certs at: http://www.mir.es/MIR/Servicios_Telematicos/ConCertificacion/ Regards, Jim Cheesman -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Philipp Gühring Enviado el: jueves, 31 de enero de 2008 3:04 Para: Eric Rescorla CC: Cryptography; Rasika Dayarathna Asunto: Re: Fixing SSL (was Re: Dutch Transport Card Broken) Hi, Huh? What are you claiming the problem with sending client certificates in plaintext is * It´s a privacy problem * It´s a security problem for people with a security policy that requires the their identities to be kept secret, and only to be used to authenticate to the particular server they need * It´s an availability problem for people that need high-security authentication mechanisms, combined with high-privacy demands * It´s a identity theft problem in case the certificate contains personal data that can be used for identity theft Quoted from Lynns email: i.e. the x.509 identity digital certificates from the early 90s, were becoming more and more overloaded with personal information ... and by the mid-90s, lots of institutions were starting to realize all that personal information represented significant privacy and liability issues ... and the RPO digital certificates were born. * It´s a liability issue (Lynn, can you go into more details here? On the other hand, I would say it´s self-explaining ...) (as if anyone uses client certificates anyway)? Guess why so few people are using it ... If it were secure, more people would be able to use it. If you want a public example of client certificate usage: https://secure.cacert.org/ (You need a (free) client certificate from www.CAcert.org to be able to access this page) There are ISPs out there who provide internet access based on client certificates, authenticated in HTTPS sessions Creative Commons is running a registry for digital works, based on authors client certificate authentication: http://www.registeredcommons.org/ The Austrian governmental inhabitant register is using client certificates for about 10,000 users all around Austria since 2001. (If I remember the details correctly) http://zmr.bmi.gv.at/pages/home.htm And there are hundreds of internal systems I heard of that are using client certificates in reality every day. That the phisher gets to see the client's identity? Validated email addresses for spamming. Spear-phishing perhaps, ... So what? Why doesn´t SSH leak the client identity in plaintext? The problem isn´t a key-agreement problem. The problem is a client-authentication problem. It doesn't let them impersonate the client to anyone. It does let them impersonate the client to anyone who doesn´t care about the public key. (There are applications that just use the DN+Issuer information that they normally extract out of the certificates, ...) But impersonation is just one threat out of the huge SSL/TLS threat-model. Certificates shouldn't contain sensitive information anyway. There are CA´s on this planet that put things like social security numbers into certificates. (I guess those CA´s would say that SSL shouldn´t leak certificates in plaintext anyway.) Shovling around responsibility won´t help us. Let´s fix the problems. (Yes, we are already trying to get those CA´s to stop doing that ... but it´s a bit like asking credit card companies to not print those sensitive creditcard numbers on those credit cards ...) And there are a lot of people who would be interested to use certificates for more applications than pure identity. (which aren´t necessarily sensitive, but they are personal related data) Where does the SSL specification say that certificates shouldn´t contain sensitive information? I am missing that detail in the security consideration section of the RFC. There is a market demand for using sensitive information in certificates, dating back to the mid 90's (according to Lynn), and showing itself in various forms like Stefan Brands credentials, Attribute Certificates, and even the OACerts by Jiangtao Li and Ninghui Li. I have been talking to many people about client certificates and client authentication, and a lot of them are interested in using client certificates for authentication, and also to add other attributes to the certificates. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... No it isn't more secure. Using username+password inside HTTPS does not leak the client
Fixing SSL (was Re: Dutch Transport Card Broken)
Hi, SSL key distribution and management is horribly broken, with the result that everyone winds up using plaintext when they should not. Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. SSL already looks quite round-trip optimized to me (at least the key-agreement part) We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? As discussed earlier on this list, layering induces excessive round trips. The SSL implementations I analyzed behaved quite nicely, I didn´t noticed any round trip problems there. (But feel free to send me a traffic capture file that shows the problem) I once implemented SSL over GSM data channel (without PPP and without TCP), and discovered that SSL needs better integrity protection than raw GSM delivers. (I am quite sure that´s why people normally run PPP over GSM channels ...) SSH has the same problems. It also assumes an active attack in case of integrity problems of the lower layer, and terminates the connection. Layering communications protocols is analogous to having a high level interpreter written in a low level language. What we need instead of layering is a protocol compiler, analogous to the Microsoft IDL compiler. The Microsoft IDL compiler automatically generates a C++ interface that correctly handles run time version negotiation, which hand generated interfaces always screw up, with the result that hand generated interfaces result in forward and backward incompatibility, resulting in the infamous Microsoft DLL hell. Similarly we want a compiler that automatically generates secure message exchange and reliable transactions from unreliable packets. (And of course, run time version negotiation) Sounds like an interesting idea to me. Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Philipp Gühring wrote: Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) re: http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken aka ... that was part of the relying-party-only certificates from the mid-90s; http://www.garlic.com/~lynn/subpubkey.html#rpo i.e. the x.509 identity digital certificates from the early 90s, were becoming more and more overloaded with personal information ... and by the mid-90s, lots of institutions were starting to realize all that personal information represented significant privacy and liability issues ... and the RPO digital certificates were born. However, it was trivial to demonstrate that (for all those business processes) that the digital certificates were redundant and superfluous (however, there was some amount of industry brain washing that digital certificates were mandatory ... especially if digital signatures was used ... even if they served no useful purpose). this also showed up in work on pk-init for kerberos supporting digital signature authentication ... and got into the confused mess with redundant and superfluous digital certificates http://www.garlic.com/~lynn/subpubkey.html#kerberos and similarly digital signatures for radius http://www.garlic.com/~lynn/subpubkey.html#radius (between kerberos and radius, they represent possibly the majority of authentication in the world today) part of the confusion regarding the necessity for digital certificates could be seen in the X9F financial standards work ... the appending of even a relying-party-only digital certificate (lacking any personal information) could represent a factor of 100 times payload bloat http://www.garlic.com/~lynn/subpubkey.html#bloat for a nominal electronic payment transactions (and also 100 times processing bloat). as a result, there was some standardization effort looking at compressed (relying party only) digital certificates (even tho they were serving no useful purpose), attempting to get the payload bloat down to possibly only 5-10 times (instead of 100 times). I took the opportunity to demonstrate that it would be logically possible to compress such digital certificates to zero bytes ... totally eliminating the payload bloat. then rather than advocating the elimination of totally useless, redundant and superfluous digital certificates http://www.garlic.com/~lynn/subpubkey.html#certless there could be an infrastructure that mandated zero-byte digital certificates appended to every transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
At Wed, 30 Jan 2008 17:59:51 -, Dave Korn wrote: On 30 January 2008 17:03, Eric Rescorla wrote: We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? Whether this is true or not depends critically on the base rate of errors in packets delivered to TCP by the IP layer, since the rate of errors delivered to SSL is 1/256th of those delivered to the TCP layer. Out of curiosity, what kind of TCP are you guys using that has 8-bit checksums? You're right. It's 16 bit, isn't it. I plead it being early in the morning. I think my point now applies even moreso :) Since link layer checksums are very common, as a practical matter errored packets getting delivered to protocols above TCP is quite rare. Is it not also worth mentioning that TCP has some added degree of protection in that if the ACK sequence num isn't right, the packet is likely to be dropped (or just break the stream altogether by desynchronising the seqnums)? Right, so this now depends on the error model... -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fixing SSL (was Re: Dutch Transport Card Broken)
On 30 January 2008 17:03, Eric Rescorla wrote: We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? Whether this is true or not depends critically on the base rate of errors in packets delivered to TCP by the IP layer, since the rate of errors delivered to SSL is 1/256th of those delivered to the TCP layer. Out of curiosity, what kind of TCP are you guys using that has 8-bit checksums? Since link layer checksums are very common, as a practical matter errored packets getting delivered to protocols above TCP is quite rare. Is it not also worth mentioning that TCP has some added degree of protection in that if the ACK sequence num isn't right, the packet is likely to be dropped (or just break the stream altogether by desynchronising the seqnums)? cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
