Re: Fixing SSL
On Thu, 31 Jan 2008 03:04, [EMAIL PROTECTED] said: > 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 Which has the problem that you may use any certifcate you ever created wit cacert.org to log in. Even certificates created for demo purposes with published private keys. That was the case up until a year ago; I don't know whether this has been changed. I was a bit surprised about such a security flaw. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Thu, Jan 31, 2008 at 02:28:30PM -0500, Anne & Lynn Wheeler wrote: > TCP requires minimum of seven message exchange for reliable transport > VMTP (rfc 1045) got that down to minimum of five messages, and XTP > then > got it down to three messages minimum for reliable transport (disclaimer > we were on the XTP technical advisory board). > SMTP does not need TCP to provide reliability for the tail of the session, the application-level "." (end-of-data) and server "250" response complete a transaction, everything after that is optional, so for example Postfix will send (when PIPELINING). DATA 354 Go ahead Message-Content Lots of acks .QUIT 250 Ok and will disconnect after reading the "250 response" without waiting for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens in the kernel in the background, the SMTP server and client are by that point handling different connections. So the reliable shutdown latency is of no consequence for application throughput. A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7. 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 3. MAIL RCPT DATA 250 250 354 4. MSG . QUIT 250 221 5. close socket TCP is fine, latency is primarily the result of application protocol details, not TCP overhead. The only TCP overhead above is 1 extra RTT for the connection setup. Everything else is SMTP not TCP, and running SMTP over UDP (with ideal conditions and no lost packets, ...) would save just 1 RTT. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
On Jan 30, 2008 9:04 PM, Philipp Gühring <[EMAIL PROTECTED]> 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 totally disagree that this is a material problem that is in any meaningful way impeding the use of SSL client certificates (there are totally different reasons that client certs aren't being widely adopted, but that's beside the point). However, TLS supports what you want right now: just do the initial handshake without client auth, then renegotiate after the session encryption starts. The renegotiation will happen under the encrypted, identity-protected and server-authenticated session, and client authentication can be requested in the renegotiation; the client cert will then be confidential. The reason nobody actually bothers to do this is because there's no customer demand (see paragraph 1). - Tim - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Victor Du Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK 1. ACK 220 2. HELO 250 3. MAIL 250 4. RCPT 250 ... n recipients RCPT 250 4+n DATA 354 5+n ... stream of message content segments 250 so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP "overhead". This is improved with PIPELINING: 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 ... PIPELINING ... 3. MAIL RCPT(n times) DATA 250 250 (n times) 354 4. ... stream of message content segments 250 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 http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken) TCP requires minimum of seven message exchange for reliable transport VMTP (rfc 1045) got that down to minimum of five messages, and XTP then got it down to three messages minimum for reliable transport (disclaimer we were on the XTP technical advisory board). i've frequently pontificated that with reliable registration of public keys in the dns system and then piggy-backing any registered public key in standard DNS response then it would be possible to encode the randomly generated secret key (with that public key) and the encrypted message in the XTP packet for minimum 3 packet exchange. http://www.garlic.com/~lynn/subtopic.html#subpubkey.html#catch22 http already went thru its period of problems of implicit assumptions with tcp. tcp sessions were assumed to be long lived and session shutdown was assumed to be relatively infrequently. non-session activity like http was always assumed to use udp for efficiency. the http ignored all of that and used tcp for non-session activity. as a result, webserver systems went thru a period where the processors was spending 95+ percent of processor in the session shutdown processing. systems then were retrofited with new kind of tcp session shutdown implementation to handle the misuse by http. the original ssl deployment was to 1) encrypt data in transit and 2) authenticate the server. the implicit assumption was that the user understood the binding between the business and the url. the browser then provided the second part, verifying the binding between the url and the server contacted (was the server that the user thot they were talking to, the server they were actually talking to). The dependency for valid ssl operation was violated almost immediately when merchants found that ssl overhead reduced thru thruput by 5-10 times. the regression was instead of initial contact of the webserver (presumably url supplied by user) being ssl, ssl was moved to checkout/pay phase where the user clicked on a button (and url) provided by the webserver (not a url provided by the user). It was no longer possible to provide any assurances as to the authentity of the webserver contacted (ssl purely being reduced to encrypting data in transmission). we had been called in to consult with the small client/server company on using this technology (they created) called SSL for payment transactions http://www.garlic.com/~lynn/subnetwork.html#gateway and had to go thru detailed walk thrus of the technology as it applied to actual business processes (and the associated implicit dependencies) ... as well as detailed walk thrus of the new business operations that were calling themselves certification authorities. the other issue that we came up in applying this SSL technology was communication between webservers and something called the payment gateway. for this communication we mandated mutual authentication ... this was before mutual authentication had been implemented in SSL. It turns out that by the time we had it all implemented and deployed ... it also became very apparent that the things called digital certificates were redundant and superfluous. the basic design point for digital certificates is first time communication between total strangers. the payment gateway business processes required that all the merchants had to be pre-registered with the payment gateway and the payment gateway pre-registered with all the merchants violating the basic justification for having digital certificates. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Jan 31, 2008, at 4:07 PM, Guus Sliepen wrote: I hope that in the future, if you see an application doing something wrong, you don't immediately give the developers the soundwave therapy. The wider point of Peter's writeup -- and of the therapy -- is that developers working on security tools should _know_ they're working in a notoriously, infamously hard field where the odds are _overwhelmingly_ against them if they choose to engineer new solutions. With such understanding, no competent developer should ever set out to build new cryptosystems unless he can explain, point by point, why his needs cannot be met by existing, vetted systems. That explanation should ideally be made public for dissection by the community. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 do
Re: Dutch Transport Card Broken
"James A. Donald" <[EMAIL PROTECTED]> writes: > Perry E. Metzger wrote: >> (No, I'm not a fan of X.509 certs, but those are not >> core to the protocol, and you can think of them as >> nothing more than a fancy key container format if you >> like. Key management is not addressed by SSL, so there >> is no reason that fixing key management has anything >> to do with SSL per se.) > > The two actually working, widely used, secure systems > are SSH and Skype, SSL is in use just about everywhere, James. https: is used constantly, and there are many other applications that make use of it. My mom uses SSL regularly, but by contrast I don't think she's ever touched SSH. Perhaps you argue that SSL is not secure, but it appears to have withstood all attacks to date. You might claim that it does not prevent phishing attacks or some such, but then you are making a claim about how people use https in practice,, not about SSL at all. The SSL part of that protocol is fine, just as the RSA and AES or 3DES parts of that protocol are fine. > neither of which uses SSL/TLS/PKI I'm going to start referring to you as James Donald/George W. Bush. Why does James Donald/George W. Bush persist in involving us in wars in foreign countries, I wonder? Please don't claim that you're not somehow part of James Donald/George W. Bush, because as you see I've juxtaposed your names, which is proof that you must be part of the same entity. If you don't like my doing that, then stop referring to SSL/TLS/PKI because SSL has nothing to do with PKI. SSL has nothing to do with PKI. X.509 certs are just a key container format. The applications get to decide what to do with them. You persistently claim that SSL has something to do with public key infrastructure, but it has no more to do with public key infrastructure at all. You shouldn't mention them at the same time. You are free to write applications that use SSL with a PKI, or without it -- the two have nothing to do with each other whatsoever. I know of many apps that use SSL and don't touch PKI at all. Constantly mentioning PKI and SSL at the same time betrays a substantial ignorance of the system architecture we're mentioning -- it would make as much sense to claim that SSL has something to do with IKE because both use X.509 certificates. > The proof of the pudding is in the eating. When large > numbers of people use cryptography that really does make > them secure, they are not using SSL/TLS/PKI. Well, James Donald/George W. Bush, I presume this means that you have a way of breaking SSL. Could you share it with us? If not, please stop conflating things that are unconnected. > SSL involves digital certificates. Not really, James Donald/George W. Bush. It involves public keys, and it provides a channel by which X.509 certificates can be exchanged, but by the same token, SSH also provides a channel by which X.509 certs can be exchanged. Should we therefore refer to SSH/PKI > The particular digital certificate format necessarily imply a PKI > structure No, James Donald/George W. Bush, that's not even remotely true. There is no requirement that you use the certs as anything other than key containers. >> My opinion (and just about everyone else's) is well >> known. > > There is a serious security problem in the network. It > needs fixing. SSL/TLS/PKI exists, yet is entirely > ineffectual in fixing it. Well, James Donald/George W. Bush, perhaps that is because SSL has nothing to do with the issue. SSL works perfectly so far as we know. The issue is that higher levels of the stack (like key management) aren't properly designed, but SSL itself is just fine. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
On Tue, Jan 29, 2008 at 12:26:21PM -0500, Perry E. Metzger wrote: > Clearly, more people need to know about "Gutmann Soundwave Therapy". > > Ivan Krstić <[EMAIL PROTECTED]> writes: [...] > > [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238 > > As it turns out, the central image of Peter's post was popularized > earlier*. > > However, Peter clearly said this first in a security context, and I > hope that the term "Gutmann Soundwave Therapy" spreads widely within > our field as a way of ridiculing the desire to invent your own crypto > algorithms and protocols. When it gets to the point where salesmen are > vaguely aware of the phrase and fear it, we will know we have done our > job successfully. As one of the main developers of tinc, I have been at the receiving end of Gutmann's therapy, or "drive-by shooting" as I experienced it at that time. Peter sent us his write-up up via private email a few days before he posted it to this list (which got it on Slashdot). I had little time to think about the issues he mentioned before his write-up became public. When it did, I (and others too) felt attacked in a cruel way. Peter ignored all the reasons *why* we used the kind of crypto we did at that moment, compared it to a very high standard, and made it feel like every thing we didn't do or didn't do as well as SSL made our crypto worthless. We had some other people sending us security reviews of tinc, Jerome Etienne for example. With them, we never had that feeling of being "attacked". The conversations we had with them encouraged us to improve tinc. Peter's write-up was the reason I subscribed to this cryptography mailing list. After a while the anger/hurt feelings I had disappeared. I knew then that Peter was right in his arguments. Nowadays I can look at Peter's write-up more objectively and I can see that it is not as ad-hominem as it felt back then, although the whole soundwave paragraph still sounds very childish ;) When tinc 2.0 will ever come out (unfortunately I don't have a lot of time to work on it these days), it will probably use the GnuTLS library and authenticate and connect daemons with TLS. For performance reasons, you want to tunnel network packets via UDP instead of TCP, so hopefully there is a working DTLS implementation as well then. I hope that in the future, if you see an application doing something wrong, you don't immediately give the developers the soundwave therapy. Be a little bit more gentle and try to find out why it was written that way in the first place. It will create a lot more understanding and willingness from the developers to fix the problems. Also, from experimenting with a version of tinc that uses TLS, I can tell you that it not the perfect solution for our problem. The main issue I see with SSL and TLS is with the credentials. Both X.509 and OpenPGP are focussed on URLs or email addresses. It is not clear to me how to store other information (like which subnets a node on the VPN is authorised to use) in such credentials in a nice way, other than shoehorning it into a CN (X.509) or uid (OpenPGP) field. Certificate chain verification is something that often goes wrong; some SSL libraries do not offer that functionality, or only do it when an application explicitly requests it. With OpenPGP you can have a web of trust, but how do you make use of it in an automated way? I expect that the next round of penis-shaped soundwave therapy will not be focussed on whether or not an application uses SSL, but on how it (mis)uses SSL. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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. > > > TC
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 probl
Re: Dutch Transport Card Broken
Perry E. Metzger wrote: > (No, I'm not a fan of X.509 certs, but those are not > core to the protocol, and you can think of them as > nothing more than a fancy key container format if you > like. Key management is not addressed by SSL, so there > is no reason that fixing key management has anything > to do with SSL per se.) The two actually working, widely used, secure systems are SSH and Skype, neither of which uses SSL/TLS/PKI The proof of the pudding is in the eating. When large numbers of people use cryptography that really does make them secure, they are not using SSL/TLS/PKI. SSL involves digital certificates. The particular digital certificate format necessarily imply a PKI structure with the same sort of defects as the existing PKI structure, which secures what does not matter much, and fails to secure that which does matter. In this sense, X.509 certificates are core to the protocol, and that is the big problem with the protocol, though neither am I happy about the fact that when the client initiates a communication, the data it actually wants to send only gets sent after the the *third* round trip. > My opinion (and just about everyone else's) is well > known. There is a serious security problem in the network. It needs fixing. SSL/TLS/PKI exists, yet is entirely ineffectual in fixing it. - 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: Gutmann Soundwave Therapy
On 30 Jan 2008, at 04:26, Perry E. Metzger wrote:
Clearly, more people need to know about "Gutmann Soundwave Therapy".
To this end, I would like to introduce the Gutmann Sound Wave Therapy
Mobile Enlightenment Unit.
http://occasionallyhuman.net/gutmann/
(NSFW if depictions of phallic audio waves are an issue)
Do you know a programmer who believes they can write a replacement for
SSL in the time it takes to finish their coffee?
Tell tale signs are phrases such as 'proprietary crypto' and 'secret
algorithm'.
Simply apply the Gutmann Sound Wave Therapy Mobile Enlightenment Unit,
stand back, wait and breath a sigh of relief - you've just made the
world a better place.
I'll begin taking pre-orders shortly.
--
Hayden
PS: I don't care that the audio wave can't be produced. It's 'artistic'.
#!/usr/bin/perl
chop($_=<>);@s=split/ /;foreach$m(@s){if($m=='*')[EMAIL PROTECTED];$x=
[EMAIL PROTECTED];$a=eval"$x$m$z";[EMAIL PROTECTED],$a;[EMAIL
PROTECTED],$m;}}print"$a\n";
# http://occasionallyhuman.net/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Wed, Jan 30, 2008 at 06:08:37PM -, Dave Korn wrote: > On 30 January 2008 17:01, Jim Cheesman wrote: > > > James A. Donald: > 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. Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK 1. ACK 220 2. HELO 250 3. MAIL 250 4. RCPT 250 ... n recipients RCPT 250 4+n DATA 354 5+n ... stream of message content segments 250 so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP "overhead". This is improved with PIPELINING: 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 ... PIPELINING ... 3. MAIL RCPT(n times) DATA 250 250 (n times) 354 4. ... stream of message content segments 250 Here the application protocol is pipelined, and 5+n RTTs becomes 4 RTTs. The solution is not replacing TCP, but reducing the number of lock-step interactions in the application protocol. If someone has a faster than 3-way handshake connection establishment protocol that SSL could leverage instead of TCP, please explain the design. The TCP handshake adds a 1-RTT delay at the start of the connection. What 0-RTT algorithm will allow the server to delay creating expensive connections to clients until the client acks the server response or discover the MSS before sending the first segment? With TCP, at least SYN floods require unspoofed client IPs. Most of the application protocols we wrap in TLS are not DNS. Sure if you can guarantee a single packet response to a single packet request, TCP is not the answer. Otherwise, claiming that SSL is less efficient over TCP smacks of arrogance. -- /"\ 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)
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]
