DV = Domain Validation - all that's validated by the certificate authority (CA) is that the person getting the certificate controls the domain

OV = Organisation Validation - the CA also checks that the person getting the certificate is the organisation they claim to be (the cert will contain, for example, a company name or number)

EV = Extended Validation - the CA does additional checks for authenticity and trustworthiness

Typically, sites with EV certificates have the address bar show up green, and the organisation name is visible in it. EV is mostly only used for stuff like online banking. Less important things like Facebook, YouTube and your blog will use cheaper and easier to get DV or OV certificates. Let's Encrypt! gives you a DV certificate since domain ownership is the sole thing it can and does validate.

It's the main product this company is selling.

Yeah I have no clue what that is.

The green bar certs that nobody in the world ever looks for.

That's an excellent point - I've added it to the article and credited you.

This is pretty reasonable provided that you're not in danger of having to stop using HTTPS. For our personal blogs, that's probably fine (and hey, I should kick up the timeout on my HSTS header, thanks for the reminder). For a site that you're making for an employer or a customer, you should be certain that they're not going to want to move it over to a non-HTTPS-compatible web host for whatever reason. Most of the time you can be confident about this; sometimes you can't. Strict-Transport-Security is a promise to your viewers that for the next whatever time period you say, you're not going to change your mind about HTTPS.

Add the Hg client to that list.

The amount of software that fails because of SNI is insane. For something that should be done systemwide by a single library, it's also too weird.

> Bing wont crawl you, you have to email the support and maybe they manually whitelist you.

They seem to be doing OK on my site. I've never contacted them.

What browser are you using on the Nexus 7? We test on current Chrome (which I imagine most Nexus 7 users are using).

It is of course good to be aware, but legacy Android versions shouldn't be a show stopper for modern TLS.

For general web browsing, I'd expect that both Chrome and Firefox are installable on Android 2.3 and bundle their own TLS libraries.

Other app developers can also vendor TLS libraries, like Bouncy Castle, to support modern encryption on legacy devices.

Luckily, libressl is being discontinued in favor of libtls, that has a saner interface. Or, better, if I understood the strategy correctly, libressl is being transformed into a wrapper of libtls, with frozen functionality until people stop using it.

The difference is that SSL was the name for the protocol Netscape invented, and TLS was the name for the protocol that went through a standardization process. SSL 1.0 was Netscape-internal and horribly broken. SSL 2.0 was less so, and after that came SSL 3.0. Then the standards process renamed it and released TLS 1.0, then TLS 1.1, and then TLS 1.2 (and there's now TLS 1.3 under development).

Those TLS versions identify themselves in the handshake as if they were SSL 3.1, SSL 3.2, and SSL 3.3, in fact.

It's basically just like how Windows NT went from 4 to 2000 to XP to Vista to 7. It's just marketing/politics, and the underlying technical version number just kept steadily ticking upwards (2000 was 5, XP was 5.1, and Vista was 6) with no regard for marketing.

Easy mode:

    - SSL is outdated
    - TLS is newer

Yes, there are a lot more differences, but if we start today we might be able to retire the use of SSLang in the future.

It's very different from WPA and WEP. "TLS" was a rebranding as part of the standardization process, for political reasons, and was not merited by any of the actual protocol changes. The wire format of TLS 1.0 looks exactly like how you'd have expected an SSL 3.1 or 4.0 to look, down to the fact that the version number field literally contains 3.1. The data structures are the same, the encoding is the same, many of the algorithms are the same, etc. And many of the protocol bugs are the same, and were only closed down in TLS 1.2.

WEP and WPA are completely different protocols. WEP only supports a shared, fixed encryption key, and in its common mode has no handshake. WPA always uses a handshake and derives a per-session key for encryption, and therefore requires a stateful client. (This is why, e.g., on Linux, you can use `iwconfig` to set a WEP password but you need to run the `wpa_supplicant` daemon for a WPA-password.) WPA's handshake supports EAP, and WEP has no concept of it. And so forth.

Perhaps you're thinking of WPA vs. WPA2? That's much more like SSL 3.0 and TLS 1.0: there was a standardization process between them, the protocol has been adjusted to address inherent security issues, there are more secure algorithms available, etc. but it's still clearly an extension of the original protocol. But here, again, most practitioners and implementors are happy to call both protocols "WPA" without any risk of confusion or inaccuracy.

> I don't generally like being a pedant, but SSL and TLS are different things that attempt to solve the same problem, much like WEP and WPA.

That is not really accurate - TLS 1.0 is very similar to SSL 3.0. They're so similar that implementations use much of the same code for both. TLS 1.0 should have been called SSL 3.1, but because of the browser wars between Netscape and Microsoft it was renamed (SSL was invented by Netscape, Microsoft didn't want to adopt a Netscape technology). See http://tim.dierks.org/2014/05/security-standards-and-name-ch...