50

I'm planning to purchase a SSL certificate for one of my sites when I'm concerned about points made in these articles:

Is SSL secure any more? What are they talking about? I thought SSL was bullet-proof, but now I'm confused.

If SSL is not secure any more, with regard to safeguarding the information exchanged between my clients and my server via HTTP, what are my options other than a SSL certificate?

IQAndreas
  • 6,667
  • 9
  • 33
  • 52
datasn.io
  • 749
  • 2
  • 8
  • 9
  • 5
    The importance of IPsec in IPv6 is often exaggerated. IPv6 is good in many ways, but IPsec is not one of the best things about IPv6. Just upgrading everything to IPv6 does not make it easy to encrypt all your traffic. You'll still be dependent on lots of infrastructure. The standard doesn't even support opportunistic encryption without involving additional infrastructure. Moreover IPsec is more complicated than it needed to be and it was eventually decided that IPsec would be an optional feature. – kasperd Nov 30 '14 at 22:26
  • It's worth noting that in [RFC 6434](http://www.rfc-editor.org/rfc/rfc6434.txt) (see section 11) it states that `Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes.`; IPsec is effectively no longer a required part of the IPv6 standards. – mpontillo Dec 01 '14 at 22:19
  • 2
    I'm surprised that no one mentioned yet that "SSL Certificates" are actually called [X.509](//en.wikipedia.org/wiki/X.509) certificates and that they are used for a lot more things than SSL (and its successor, TLS). – user2428118 Dec 02 '14 at 19:17
  • 1
    You can also get free certs now here: https://letsencrypt.org/ – gsgx Dec 04 '14 at 06:48

4 Answers4

89

All except the third link refer to SSLv3 (version 3) which is affected by the poodle vulnerability. You should be using the TLS protocol which is the successor of SSL and not affected. You should configure your web server to support TLS 1.0, 1.1 and 1.2, which should cover most devices out there save for a few archaic ones like IE6.0, while still remaining secure. The certificate used for both protocols is the same.

Most mass media websites refer to TLS/SSL as simply SSL. They are actually two separate protocols.

More information here : What's the difference between SSL, TLS, and HTTPS?

As for the 3rd link, it refers to IPv6 superceding SSL. My opinion is that it will take at least a few more years for IPv6 to become the de-facto addressing scheme. In the mean time, an SSL certificate will secure your site. Afterall, you can buy a cert for 1-2 year duration if you are afraid it will become obsolete in the near future.

Community
  • 1
limbenjamin
  • 3,944
  • 50
  • 72
  • 1,281
  • 21
    Only a few more years for IPv6? I think it's safe to purchase a TLS certificate. – RoraΖ Nov 30 '14 at 13:16
  • 3
    @Kroltan, actually it's both. :) See multiple arcane IE 6 bugs like hasLayout and the [guillotine bug](http://www.positioniseverything.net/explorer/guillotine.html). – Matthew Flaschen Nov 30 '14 at 19:02
  • @MatthewFlaschen What the...? Well, at least it renders. – Kroltan Nov 30 '14 at 19:22
  • 4
    Whoever wrote that article has never deployed IPSec, either in IPv6 or IPv4, and has no real understanding of how it works. If he did, the article would never have been written; it's about 99% wrong. We will continue to use TLS with IPv6 for the foreseeable future. – Michael Hampton Dec 01 '14 at 16:32
  • 2
    Agreed with @MichaelHampton regarding IPSec. Also, IPv6 has been 'a few years away' for about 15 years now. It was originally specified in RFC 1883 in **1995**. – reirab Dec 02 '14 at 06:28
  • +1 However, it would also probably be wise to stay away from TLS 1.0 these days, too, if at all possible. – reirab Dec 02 '14 at 06:35
  • We've found that dropping TLS 1.0 breaks all kinds of enterprisy stuff. Be careful... :-) – Brian Knoblauch Dec 02 '14 at 16:35
28

You're running into a bit of terminology confusion. SSL can mean two things:

  1. The Secure Sockets Layer protocol, versions 1, 2, or 3.

  2. The generic SSL/TLS family of security protocols.

SSL definition 1 is thoroughly obsolete and should not be used. SSL definition 2 is still very much alive, with the good pieces of SSL definition 1 (such as much of the certificate mechanism) incorporated into the modern TLS standards.

Mark
  • 34,513
  • 9
  • 86
  • 135
12

Infosec Island: IPv6 - The Death of SSL

The article talks about the use of IPSec as integral part of IPv6 instead of SSL/TLS. IPSec mainly moves the encryption from application layer to the transport layer.

But, the main problem with SSL/TLS are not flaws in the protocol or in the crypto code. Instead the main problem is the PKI, that is the proper use of certificates and CA to build and propagate trust and thus provide trustable authentication. IPSec has no improvements in this area. Even if IPSec will be used everywhere it will probably use the same broken PKI we already use with SSL/TLS. And certificates are needed in both cases.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 4
    SSL/TLS getting replaced with IPSec is indeed very unlikely. It is not like IPSec provides any improvements in terms of PKI, and really that is the weakest point of both protocols. If anything is going to replace SSL/TLS as we know it, it is most likely going to be SSL/TLS with the CA infrastructure replaced with public keys published through DNSSEC. – kasperd Nov 30 '14 at 22:08
  • 2
    @kasperd which is not going to happen all that soon - there is strong opposition within the IETF to putting application keys into DNS. There is [RFC 4387](http://www.ietf.org/rfc/rfc4387.txt), but it is not seeing notable implementations in clients as of today – syneticon-dj Dec 01 '14 at 22:01
  • @syneticon-dj Not sure what's the reason for opposition to that idea. It addresses two of the major flaws in the current CA infrastructure. First of all since any CA can issue certificates for any domain, the security of that system can be no stronger than the weakest CA. Many CAs accept the ability to receive an unencrypted mail sent to the domain as sufficient proof of ownership, and building something on top of DNSSEC is the only way a strong proof of ownership of the domain could be build. – kasperd Dec 01 '14 at 22:42
  • @kasperd I understand the main line of reasoning is that DNS zones should not contain data unrelated to DNS, so basically it is about conceptional cleanliness. The problem you are describing might be fixed by a well-designed and well-implemented name constraint mechanism. X.509 [has name constraints specified as of RFC 5280](http://tools.ietf.org/html/rfc5280#section-4.2.1.10), but [these are defunct](http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/) in most implementations, making them essentially useless. – syneticon-dj Dec 01 '14 at 23:41
  • @syneticon-dj That argument does not make specifying a public key in DNS any less appropriate than SPF and domainkey records. Additionally if you want to communicate securely, then knowing the public key of the server you are connecting to is just as important as knowing its IP address. – kasperd Dec 02 '14 at 12:12
  • @kasperd the point I am making that the certification authority for a name space belongs with the registration authority for this very name space - in the case of DNS names this would be the DNS zone admin. The exact mechanism of publication for the resulting certificates does not matter that much. But it seems I was mistaken about putting application keys into DNS. It has been a couple of years I have last tried to air this topic with IETF working group members. In the meantime, the [DANE working group](http://datatracker.ietf.org/wg/dane/documents/) proposing this very thing has formed. – syneticon-dj Dec 02 '14 at 20:18
  • @syneticon-dj I agree that the certification authority for a name space belongs with the registration authority for that name space. My point is that by publishing certificates through DNSSEC there is a trust chain from that authority to the certificate. The current CA system does not have any such trust chain. The publication method isn't important, the trust chain is. DNSSEC provides both the trust chain and the publication method. – kasperd Dec 02 '14 at 21:46
  • @kasperd there is a trust chain in X.509 certificates, but it is a chain of certification authorities only. Either way, the big CA players are not going to give up their gold mine easily, so we probably will see another couple of years go by before the PKI for the general public will start changing. – syneticon-dj Dec 02 '14 at 22:09
  • @syneticon-dj X.509 certificates have a trust chain, but their trust chain is broken. They do not have a trust chain from the authority of the domain to the server certificate. The starting point of their trust chain is not well defined, instead it could be whatever an attacker want it to be. The attacker would have to chose from a finite list of possible starting points put in the client code, but if even one of those starting points is not to be trusted, the entire security breaks down. – kasperd Dec 02 '14 at 23:17
12

Aside from the other good answers about the SSL vs TLS vs certificate confusion, the question of whether you should continue to "buy" a SSL certificate may be influenced by the upcoming launch of Let's Encrypt (sponsored by the EFF, Mozilla, et al), which will start offering free and turnkey SSL certs in 2015.

Unless you need a fancy certificate (EV, wildcard, and so on, which Let's Encrypt may not necessarily be able to provide), you will be able to use their certs on your site without needing to pay a cent.

Although there are already some other CAs that offer free certificates (with Startcom being one of the better-known examples), I believe that Let's Encrypt will be the first major player to extend a free offering to commercial sites too.

Scott Dudley
  • 301
  • 1
  • 3
  • 2
    While I'm excited about this development I'm going to state the obvious: Let's Encrypt is not yet available and it remains to be seen if browser vendors, other than Mozilla, will trust its root-certificate. It will not be very useful otherwise, a problem CAcert.org can relate to. In the meantime I'd suggest shopping around for a certificate (or getting a free one from Startcom). They're quite affordable and are currently your best bet. – Martijn Heemels Dec 01 '14 at 17:42
  • 1
    Skimming the technical summary suggests that "Let's Encrypt" offers no authentication (assurance of identity) at all. Every site defacement attack now enables the attacker to acquire new CA-signed certificates? Not a good thing. – Ben Voigt Dec 01 '14 at 18:27
  • 4
    Looks to me like they use the same type of authentication that's used for entry level SSL certs from the mainstream cert providers. You prove you control the domain by publishing a key they provide, basically the same thing as having you reply to an email to prove you own the address. Given the alternative of having no SSL in place at all, I can't see this as bad. – barbecue Dec 01 '14 at 21:10