- As a browser, by using a default OS and watching the root CA store. You can control the key stores on most devices except iOS pretty easily: https://certsimple.com/blog/control-the-ssl-cas-your-browser...
- As a server, setting up key pinning (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) which throws up a browser warning if someone accesses your site with a new key.
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.
Our product is 40-100x faster validation for EV. If you think DV is fine for your app, that's awesome. But if you're thinking about getting an EV cert, we do in an average of 5 hours what others do in 7-10 days.
So it's not just that it slows down your site, it slows down your site without any additional security or other benefit.
Can we please, as a society, try to move forward with the correct acronym? Everyone who isn't wide-open-vulnerable is using TLS 1.0 or newer. (Personally, I like to run TLS 1.2 only, but my CloudFlare domains still speak 1.0 and I can't turn it off without paying money.)
This won't happen as long as OpenSSL (or libressl) is popular.
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.
- SSL is outdated
- TLS is newer
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.
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...
Important reading: http://webmasters.stackexchange.com/a/9095
It's very easy to do, and ensures all your users get maximal security. The future is encrypted.
Today I did this for my blog: https://github.com/TazeTSchnitzel/blog/commit/792986d18d8583...
You really only need two ciphers to get to most browsers/clients and good security and speed (replace RSA with ECDSA if needed):
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Example: https://www.ssllabs.com/ssltest/analyze.html?d=theandrewbail...
It baffles me that Mozilla recommends 20 ciphers for their highest security level. I think high security should be more exclusive than that, and with forward secrecy only.
Point 5:
How I imported Let's Encrypt's certificates into a Java keystore:
openssl pkcs12 -export -name yourdomain -in fullchain.pem -inkey privkey.pem -out pubchainpriv.p12
keytool -importkeystore -srcstoretype pkcs12 -srckeystore pubchainpriv.p12 -alias yourdomain -destkeystore /path/to/keystore.jksAlso potentially add an aside for self-signed/enterprise CA, as most web developers will encounter internal systems sooner or later. This makes the above (consuming services) more challenging :-)
Bing wont crawl you, you have to email the support and maybe they manually whitelist you.
A lot of RSS readers wont work, services like pocket, reddit submissions, mailchimp rss to email etc etc.
It's crazy considering we want to move everything to https only.
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.
So many things are broken because of it. It doesn't have native SNI capability.
They seem to be doing OK on my site. I've never contacted them.
I see the top navigation followed by a white page, no scrollbar.
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.