9 ms·
Forthcoming OpenSSL releases
- oleganza 11y agoEvery time some OpenSSL bug is announced, I remember my issues with TLS (I don't know if this bug is TLS-related or not). Would be nice if TLS supported: 1) "hot" certificates with 24h ttl signed-off by a longer-living certificate on a more secure machine. Having 1-year certificate private key deployed on a web server is crazy. Especially since revocation does not really work. 2) Threshold multi-signature certificates for both CAs and end-user certificates. 3) CA certificates locked to specific TLDs (was there RFC about something like that already?) - so Russian CA cannot sign certificate for a Canadian TLD. 4) Ultimately, blockchain name pinning on DNS level. The last three do not really relate to a case when bug in OpenSSL reveals a private key stored on web server.
- iancarroll 11y agoThere is no limitation in TLS preventing you from cycling your keys every 24 hours. Most CAs let you do unlimited reissuance. It makes public key pinning hard (impossible?), though.
- rakoo 11y ago> It makes public key pinning hard (impossible?), though. In this case you don't pin the server's key but the "central" key.
- sneak 11y agoThis doesn't really work without the certificate expiration date also being 24-48h in the future, though. I think they reissue the same 1y+ validity cert...
- iancarroll 11y agoSome allow manually specifying the expiration times.
- skuhn 11y agoEntrust, for instance, allows you to purchase certs essentially on a subscription plan. You may have one valid cert for 3 years (and pay the reduced 3 year rate), and reissue it with 24 hour expirations every day. I personally wouldn't go with an expiration that low because of the operational overhead, but a few weeks or a month is attractive. It still significantly limits the downside potential versus 1-3 year certs. Basically any cert (non-root) over 1 year should be considered against best practice at this point.
- dfc 11y agoWhat problem does #1 solve?
- rakoo 11y agoIt makes losing/leaking a private key less of a problem, because it restricts the leakage to a 24h window. It also makes (webserver) key revocation kind of useless, because the certificate is automatically invalid after 24h.
- kpcyrd 11y ago4: Namecoin supports this, if I recall correctly, but I recommend to pull this value out of your local blockchain instead of dns.
- sebiw 11y ago4) would only make sense with signed DNS responses
- Xylakant 11y ago1) could be solved by a HSM or a similar construction in software. The private key never ends up on the web server this way.
- erglkjahlkh 11y ago3) Does anyone have any reference to this?
- antsar 11y agoHere's [0] the relevant section of the X.509 RFC (Name Constraints). Unfortunately, last time this was discussed on HN, someone mentioned that Name Constraints are not supported by all client software, making it unsafe to rely on them. [0] http://tools.ietf.org/html/rfc5280#section-4.2.1.10 http://tools.ietf.org/html/rfc5280#section-4.2.1.10
- zokier 11y agoI'd imagine (based on very superficial knowledge) that DANE would achieve something to that effect. But it's pretty much dead because apparently DNSSEC wasn't all that great.
- nothrabannosir 11y agoThe fact that 3) was not built-in from the start pains me to no end. It should be flying first-class with Priority Airlines, a penthouse in the Hilton bugtracker since 1996. Instead, it's #3 in someone's list somewhere in a forum in 2015.
- antsar 11y agoAFAIK it was built-in from the start, as far as the X.509 protocol is concerned. Its just not used anywhere. http://tools.ietf.org/html/rfc5280#section-4.2.1.10 http://tools.ietf.org/html/rfc5280#section-4.2.1.10
- nothrabannosir 11y agoOh my God! What? How is this not a major, major thing? How are Mozilla and Google not pushing hard for government CAs to have these, like, stat? And for OpenSSL to actually check them? I am bewildered. What happened? Is this just apathy? http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/ http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... Unbelievable. This is SRV for HTTP all over again. The Betamax of the 21st century.
- deleted 11y ago[deleted]
- ab 11y agoEnforcement of nameConstraints is inconsistent at best. I experimented with name constraints a couple years ago for a private CA project, with the idea that I could restrict the private CA to issuing only names within a chosen subdomain. I remember being able to enforce nameConstraints on the subjectAltName, but I was never able to get it to enforce anything on the subject Common Name. In theory new certificates should always have a critical subjectAltName extension, but this makes it worthless in practice. It's also possible that my X.509 foo is not strong enough, or that I was testing with an older version of OpenSSL that doesn't implement it. http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/ http://blog.codekills.net/2012/04/08/adventures-in-x509-the-...
- ad_hominem 11y agoI don't understand #1 - what prevents you from doing this today? When you generate a certificate you get to pick the expiration date; you are free to make it as short as you want. Don't intermediate certificates exist to implement this strategy? edit: basically, what stops you from doing this? Root CA root cert (20y expiration) v Root CA intermediate cert (10y expiration) v Your intermediate cert (1y expiration) v Your short-lived cert (24h expiration)
- amluto 11y agoAnd who is going to issue you a reasonably-priced intermediate cert? Especially since PKIX name constraints don't actually work, so that intermediate cert would let you sign just about anything.
- chair6 11y agoRegarding #1, check out Anchor - https://wiki.openstack.org/wiki/Security/Projects/Anchor https://wiki.openstack.org/wiki/Security/Projects/Anchor - an ephemeral PKI system coming out of the OpenStack community. In brief, it attempts to address weaknesses in PKI operations and specifically revocation capabilities by allowing issuance of short-lived certificates based on a set of validation rules. The README has some detail about the tool, http://git.openstack.org/cgit/stackforge/anchor/tree/README.md http://git.openstack.org/cgit/stackforge/anchor/tree/README..... A recent presentation is at https://www.youtube.com/watch?v=Q_ZhrQq-_YM https://www.youtube.com/watch?v=Q_ZhrQq-_YM.
- viraptor 11y agoJust in case the stackforge link disappears, the project is being moved right now into OpenStack proper. There's no dependency though, so you can easily use it on its own. We'll release version 1 soon, so the API will change just a little bit, but the main idea remains: issuing short lived certificates from a single location (or multiple, it works without changes in multi master mode). If you have any configuration issues, get in touch, we're happy to hear about new use cases for this tool.
- mugsie 11y agoThere is still the issue of the CA that is in place for anchor - your users have to trust it.
- viraptor 11y agoYes, the main reason it was created is OpenStack deployments where Anchor is used for securing internal communications, so the PKI is an internal one (most likely). We cannot change how the CAs work in public networks unfortunately, but if they do, we're going to be ready :)
- nocarrier 11y agoHere's some techniques to address #1: 1. Store your private keys in a separate process, either on the same machine or a remote, more secure host. Offload private key operations to the private key service. This obviously requires an encrypted connection between your webserver and the private key service, but you get good gains in security from no longer having the private key in your public facing web server's address space. 2. Another technique you can add is to separate the data plane from the control plane on your public facing webserver--that way you have a stripped-down process that is just handling the low level reading and writing of buffers to the wire, and have a fast pipe connecting it to a separate process doing all the HTTP logic. That way, you can lock down the data plane service and make it harder to exploit since it has a much smaller surface area than a full fledged web server.
- ams6110 11y agoYour webserver needs access to the private key when it starts. Is it really a big enough gain to be worth it to move it to another server? If I root the webserver, I can presumably just read the key from that service.
- xorcist 11y agoThe webserver process does not need access to private keys, just access to the encryption service ("TLS offloading").
- ams6110 11y agoOK, so if my TLS temination host gets rooted.... I guess the assummption is that host is hardened and less likely to be exploited since it's just doing one well-defined thing? My ignorance may be showing, how would I copmpletely isolate the private keys from the public-facing service? I suppose using an accelerator card would do it?
- wolf550e 11y agoNo accelerator card needed. You run an "RSA signing server" that accepts connections only from the internal IP of your webserver (or maybe only TLS connections from across the internet but only if the client connecting to it has a client certificate signed by your own self-signed CA, but that depends on topology). It runs a very simple app that accepts requests to sign something and responds with the <something> signed by your RSA private key. The code for this is very minimal and secure. You teach your web server to use this thing during TLS handshake, to sign the ephemeral key exchange. If the web server is hacked, the hackers gain the ability to sign things with your private key, but they don't get the private key itself. They need to hack the "RSA signing service" server for that. They can't stockpile signed ephemeral key exchanges. After you detect the hack, snapshot and kill the hacked server, start a new one from clean backup, they lose the ability to impersonate your site. CloudFlare have a writeup on their service that does this (TLS negotiation by their TLS terminator with only you holding the key): https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
- JoshTriplett 11y ago> 1) "hot" certificates with 24h ttl signed-off by a longer-living certificate on a more secure machine. Having 1-year certificate private key deployed on a web server is crazy. Especially since revocation does not really work. This seems like the kind of thing that Let's Encrypt could be good at: if you have a fully automated renewal process, why have certificates last a long time?
- amluto 11y agoIt's the kind of thing that QUIC supports out of the box.
- JoshTriplett 11y agoHow so? What in QUIC makes it easier to have short-lived certificates?
- vbezhenar 11y ago#3: What about .com, .org, .name and many more domains? Who will control them?
- xorcist 11y agoVery short lived certificates instead of broken revocations is bascially what DNSSEC gives you. (It's apparently "dead" around here, but then again so is IPv6...)
- seanieb 11y agoCould this be related to the hacking team dump?
- eyeareque 11y agoProbably not. It sounds (and looks) like they had bad security practices.
- qrmn 11y agoI think what the grandparents is wondering is if Hacking Team have a 0day in OpenSSL which this will fix, or is the timing coincidental? (I don't know the answer, but if they did, it's probably in that 400GB dump.) I'm mostly just wondering what they mean by HIGH. Something as bad as code execution or Heartbleed, or "just" something like bad DHE checking?
- tedunangst 11y agohttps://www.openssl.org/about/secpolicy.html https://www.openssl.org/about/secpolicy.html
- qrmn 11y agoA policy which unfortunately lumps DoS in with remote code execution as both "high". They're both significant, but one's clearly going to give us all a much worse day than the other, so we're all still left to wonder - how bad is this one?
- hannob 11y agoI asked this on twitter and Mark J Cox from OpenSSL answered that it is not: https://twitter.com/iamamoose/status/618085591922679808 https://twitter.com/iamamoose/status/618085591922679808
- ctz 11y agoThis announcement narrows down the proximate cause of the bug to changes introduced in the 1.0.1 line. Assuming this is a defect in a new feature (rather than a bugfix which went awry) that means there's a fairly limited number of culprits: SCTP, DTLS-SRTP, NPN, RSA-PSS, TLS v1.1, TLS v1.2 or SRP. FWIW, I'll take SRP for 300.
- tptacek 11y agoThere was a sort-of interesting memory corruption flaw in OpenSSL 1.0.1 SRP (it was interesting because the corrupted copy was implied in bignum operations, so you had to squint at look at OpenSSL BN code as string copies). I remember when our team found it, we looked somewhat carefully at the rest of the code for similar flaws. SCTP and DTLS seem a little more likely. Edited: tired, forgot to write "SRP" in the first sentence.
- eyeareque 11y agowhat is safer: Running backdoor'ed RSA bsafe (http://www.theverge.com/2013/12/20/5231006/nsa-paid-10-million-for-a-back-door-into-rsa-encryption-according-to http://www.theverge.com/2013/12/20/5231006/nsa-paid-10-milli...) or OpenSSL? Serious question.
- tptacek 11y agoThis is a weird question, since there's almost nothing that uses RSA's library as their TLS library. Every mainstream OS BSAFE is available for already provides a TLS library. This is a little like asking whether it's safer to use PHP or DTLS.
- eyeareque 11y agoMany banks weren't vulnerable to heartbleed (they use BSAFE I've heard).
- tptacek 11y agoNo.
- eyeareque 11y agoReally? What library did they use? Ref: http://www.gospelherald.com/articles/50890/20140414/heart-bleed-bug-update-chase-boa-citigroup-irs-affected-security-flaw.htm http://www.gospelherald.com/articles/50890/20140414/heart-bl...
- tptacek 11y agoGospel Herald I don't even.
- eyeareque 11y agoIt was posted on many sites, that was the first hit from a search query. I know. http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ http://mashable.com/2014/04/09/heartbleed-bug-websites-affec... scroll to the banks section, you can see that many of them weren't affected. I've looked around online to see what they use, but it doesn't seem to be posted anywhere. My first question was serious--If there is a secure and reliable commercial ssl library out there, I know people would pay for it. No one wants to deal with these reoccurring OpenSSL issues while they work to clean up their code.
- tptacek 11y agoRich Salz suggests this is unlikely to affect most users. https://twitter.com/RichSalz/status/618145532763054080 https://twitter.com/RichSalz/status/618145532763054080
- nickpsecurity 11y agoGiven the OpenSSL trackrecord [1], I recommend switching to LibreSSL [2] if possible. They tore through OpenSSL to pull out all the horrors they found and beat it into shape. OpenSSL's code was so unbelievably bad that there's certainly more problems lurking in there. [1] http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.htm... [2] http://www.libressl.org/releases.html http://www.libressl.org/releases.html
- bascule 11y agoOr BoringSSL: https://boringssl.googlesource.com/boringssl/ https://boringssl.googlesource.com/boringssl/
- Rafert 11y agoHas Google changed their stance on not wanting BoringSSL to be a replacement for OpenSSL as an open source project? https://www.imperialviolet.org/2014/06/20/boringssl.html https://www.imperialviolet.org/2014/06/20/boringssl.html
- bascule 11y agoNo, although I've been pinging Ben Laurie on having them slap version numbers on it periodically. I think that'd be nice. The (perhaps obviously biased) TLS Under Siege talk by Google's Neel Mehta ranked BoringSSL #1 (of 2) when it came to OpenSSL forks, FWIW: https://ruxconbreakpoint.com/assets/2014/slides/TLS%20Under%20Siege.pdf https://ruxconbreakpoint.com/assets/2014/slides/TLS%20Under%...
- shthed 11y agoWould the fix have already been committed to source but the security implications not been made public yet?