Re: [cryptography] Request - PKI/CA History Lesson
Jason Iannone jason.iann...@gmail.com writes: With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf, chapter PKI. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 16/04/2014 16:30 pm, Jason Iannone wrote: The more I read, the more bewildered I am by the state of the PKI. No, not nearly enough: http://iang.org/ssl/pki_considered_harmful.html http://iang.org/ssl/ The trust model's unwieldy system[1] of protocols, dependencies, and outright assumptions begs to be exploited. Add to that the browser behavior for a self-signed certificate (RED ALERT! THE SKY IS FALLING!) compared to a trusted site and we're in bizarro world. Worse, consider Firefox's behaviour: it considers a certificate-secured site such as a self-cert'd site to be dangerous, but it does not consider a HTTP site to be dangerous. So it tells the user HTTP is safe, whereas an attempt to secure means that the user is being robbed! Go figure... Worse still, Firefox actually deceives and lies about the status of good certificates. If there is an ordinary SSL site, it shows it as white, same as HTTP. Icons and indicators are downplayed, lost in the noise. Worse again: If you click on the icon to ask, it says you are connected to www.example.com which is run by ( *UNKNOWN* ) even though the browser has a certificate that states clearly who runs the site. Try this site which is run by Google, as it says in the cert: https://developer.android.com/ Looking deeper it states: Owner: This website does not supply ownership information. One can only assume Firefox is upselling you to green certs, but lying and deceiving in the process. Chrome says something different, which I don't understand, but it doesn't seem to be quite so blatant. Is there any wonder nobody trusts any of it? I'd rather we close the gap and appreciate a secure transaction with an unauthenticated party than proclaim all is lost when a self-signed key is presented. I see no reason to trust VeriSign or Comodo any more than Reddit. Assuming trust in a top heavy system of Certificate Authorities, Subordinate Certificate Authorities[2], Registration Authorities, and Validation Authorities[3] in a post bulk data collection partnership world is a non-starter. The keys are compromised. With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. Maybe a tottering complex recursive heirarchical system of trust is a really great idea and I just need to be led to the light. Sigh. You're thinking of it as a hierarchy of trust. That isn't what it is. There's no trust anywhere in the system, even the word 'trust' as used means a mandated obligatory acceptance, not trust as humans know it. [1]http://csrc.nist.gov/publications/nistpubs/800-15/SP800-15.PDF, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf [2]https://www.eff.org/files/DefconSSLiverse.pdf, https://www.eff.org/files/ccc2010.pdf [3]http://en.wikipedia.org/wiki/Public-key_infrastructure I just ate breakfast, no thanks :( iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?
On 15/04/2014 21:07 pm, d...@deadhat.com wrote: http://clearcryptocode.org/tls/ Probably not going to happen, but it's nice to dream... It is one of my long term, implausible goals to replace TLS with a collection of independent app to app function-targeted security protocols that are individually simple enough to understand and implement cleanly. I will certainly fail. It's certainly possible. It's more or less what I do. Adoption and generating the commercial feedback cycle to finance the programmers is the problem, not the technology. E.G. For paying with a credit card.. A secure credit card payment protocol For authenticating a web site and producing keys to bind .. A web page authentication protocol. For remotely logging into a shell producing keys to bind .. A secure shell login protocol. There are many more possibilities. Today, SSL and TLS with all that entails (ASN.1, X.509, PKCS, TCP/IP etc.) is the hammer and any securable thing is the nail. But it's really a client-server session privacy and integrity protocol with issues. It isn't designed to protect my banking transactions, just the traffic over which I communicate my transaction intent. If I had a secure bank transaction protocol independent of TLS, heartbleed wouldn't matter. A classic mismatch between TLS and its primary use securing web traffic is the failure of a virtual server to be able to produce the right cert for the right virtual web site. The cert is really identifying the TLS termination point which may be a web server, rather than a web site, of which the server may be serving many. That's one reason why a web-site security protocol would be more effective than TLS plumbed under HTTP. TLS does need nuking so we can replace it with simpler things. The sentiment isn't wrong, it's just hard to pull off. For amusement, someone pointed me at the tcpcrypt group on the IETF sites. So I spend some days reading and got dragged into conversation. It's weird, I don't think I could design a more flawed process if I tried. But the good thing is that while the IETF working groups are focussed on breaking TCP, others are working to replace it. The question is, how to best replace it? Recent discussions indicate that there are many ways to do this, and the space defies easy cataloging. Which means that the formal, committee, standards, consensus group approaches won't work. How then to replace? And indeed is it a replacement or a bypass, an evolution or a revolution? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-25, at 4:09 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf In which Peter says: The major lesson that we’ve learned from the history of security (un-)usability is that technical solutions like PKI and access control don’t align too well with user conceptual models Exactly. If, for example, a user needs to understand the distinction between “trust as an introducer” versus “trust the identity of” in order to behave securely, then the system is going to fail. Or as I’ve said in http://blog.agilebits.com/2012/07/03/check-out-my-debit-card-or-why-people-make-bad-security-choices/ when we observe people systematically behaving insecurely, we have to ask not how can people be so stupid” but instead “how is the system leading them to behave insecurely.” I hated X.509 when it was first being introduced, and much preferred PGP’s “Web of Trust”. I still hate X.509 for all of the usual reasons, but I now have much more sympathy for the design choices. It fails at its goal of not demanding unrealistic from ordinary users, but at least it tries attempts to do so. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Fri, Apr 25, 2014 at 1:42 AM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: As with let's replace C with My Pet Programming Language, you can write crap in any language you want. The problem isn't the language There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. The problem is very much the language. C has too many sharp edges to write crypto code safely. Heartbleed has also done a great job of illustrating that all the band-aids they try to put on these sharp edges are also flawed. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Fri, Apr 25, 2014 at 3:10 AM, ianG i...@iang.org wrote: Worse, consider Firefox's behaviour: it considers a certificate-secured site such as a self-cert'd site to be dangerous, but it does not consider a HTTP site to be dangerous. So it tells the user HTTP is safe, whereas an attempt to secure means that the user is being robbed! I actually brought this up with one of Chrome UX engineers, specifically how to Joe User the address bar makes it appear that plaintext HTTP is more secure than HTTPS with an untrusted cert. While one is MitM-able by an active attacker, the other is most certainly being passively MitMed by someone! :O The response was that users have an expectation of security when using HTTPS that they don't with HTTP, but I wonder, how many people just think they're safe because of the absence of scary warning signs and have no idea what HTTP vs HTTPS actually means? I think plaintext HTTP should show an lock with a big no sign over it or something to highlight to users that the connection is insecure. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On 04/25/2014 06:28 PM, Tony Arcieri wrote: On Fri, Apr 25, 2014 at 1:42 AM, Peter Gutmann pgut...@cs.auckland.ac.nz mailto:pgut...@cs.auckland.ac.nz wrote: As with let's replace C with My Pet Programming Language, you can write crap in any language you want. The problem isn't the language There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. But that's just cherry-picking, and not a complete argument. Clearly, there are many other important factors to consider (good luck finding a competent rust developer). There are also whole classes of bugs in memory-safe languages that can't occur in C, for example anything related to garbage collection. That's not a complete argument either, but it shows how unconvincing arguments based on individual features must be. The real tragedy is that we still don't know how to develop good software in any scientifically meaningful sense. We have some experimental data, and a lot of folklore, but that's about it. Heartbleed has also done a great job of illustrating that all the band-aids they try to put on these sharp edges are also flawed. Actually, we don't even know what direct damage the vulnerability in heartbleed caused, if any at all. From an economical point of view, heartbleed probably was much less harmful than many other software engineering failures, including those that were done purposefully with good intentions, and/or in safe languages. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Friday, April 25, 2014, Marcus Brinkmann marcus.brinkm...@ruhr-uni-bochum.de wrote: There are also whole classes of bugs in memory-safe languages that can't occur in C, for example anything related to garbage collection. Rust doesn't have a garbage collector. It uses region typing so garbage collection is unnecessary. This is also the main thing that makes Rust an interesting tool for use cases where C/C++ would be the only viable options. Rust is a systems programming language suitable for things like kernel development or RTOS-free bare metal development on microcontrollers. Anyway, I'd suggest reading a bit more about how it works before dismissing it out of hand. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] OT: Speeding up and strengthening HTTPS connections for Chrome on Android
Somewhat off-topic, but Google took ChaCha20/Poly1305 live. http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html Earlier this year, we deployed a new TLS cipher suite in Chrome that operates three times faster than AES-GCM on devices that don’t have AES hardware acceleration, including most Android phones, wearable devices such as Google Glass and older computers. This improves user experience, reducing latency and saving battery life by cutting down the amount of time spent encrypting and decrypting data. To make this happen, Adam Langley, Wan-Teh Chang, Ben Laurie and I began implementing new algorithms -- ChaCha 20 for symmetric encryption and Poly1305 for authentication -- in OpenSSL and NSS in March 2013. It was a complex effort that required implementing a new abstraction layer in OpenSSL in order to support the Authenticated Encryption with Associated Data (AEAD) encryption mode properly. AEAD enables encryption and authentication to happen concurrently, making it easier to use and optimize than older, commonly-used modes such as CBC. Moreover, recent attacks against RC4 and CBC also prompted us to make this change. ... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OT: Speeding up and strengthening HTTPS connections for Chrome on Android
On 25/04/2014 22:14 pm, Jeffrey Walton wrote: Somewhat off-topic, but Google took ChaCha20/Poly1305 live. http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html Earlier this year, we deployed a new TLS cipher suite in Chrome that operates three times faster than AES-GCM on devices that don’t have AES hardware acceleration, including most Android phones, wearable devices such as Google Glass and older computers. This improves user experience, reducing latency and saving battery life by cutting down the amount of time spent encrypting and decrypting data. To make this happen, Adam Langley, Wan-Teh Chang, Ben Laurie and I began implementing new algorithms -- ChaCha 20 for symmetric encryption and Poly1305 for authentication -- in OpenSSL and NSS in March 2013. It was a complex effort that required implementing a new abstraction layer in OpenSSL in order to support the Authenticated Encryption with Associated Data (AEAD) encryption mode properly. AEAD enables encryption and authentication to happen concurrently, making it easier to use and optimize than older, commonly-used modes such as CBC. Moreover, recent attacks against RC4 and CBC also prompted us to make this change. ... Progress for OpenSSL! Here's hoping they also see the light and drop every other ciphersuite as fast as they can. We hope there will be even greater adoption of this cipher suite, and look forward to seeing other websites deprecate AES-SHA1 and RC4-SHA1 in favor of AES-GCM and ChaCha20-Poly1305 since they offer safer and faster alternatives. Close! 2 is s much closer to 1, it's even O(1). iang ps; obligatary toot: http://iang.org/ssl/h1_the_one_true_cipher_suite.html pps; Google, take your lead from Guus: ... It also *does not support any cipher suite negotiation*, instead it always uses a fixed suite (the current implementation[2] uses ECDHE-Curve25519-Chacha-Poly1305). The man! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OT: Speeding up and strengthening HTTPS connections for Chrome on Android
On Fri, Apr 25, 2014 at 5:36 PM, ianG i...@iang.org wrote: On 25/04/2014 22:14 pm, Jeffrey Walton wrote: Somewhat off-topic, but Google took ChaCha20/Poly1305 live. http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html ... It also *does not support any cipher suite negotiation*, instead it always uses a fixed suite (the current implementation[2] uses ECDHE-Curve25519-Chacha-Poly1305). Where is this last bit quoted from? The full suite as (pictured) in the blog is: ecdhe_rsa_chacha20_poly1305. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
