11 ms·

What web developers should know about SSL

222 points by mikemaccana 11y ago

mikemaccana 11y ago
A less common question we get, that a lot of web devs are interested in is 'How do I mitigate against MITM attacks'. - 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-trusts 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 https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) which throws up a browser warning if someone accesses your site with a new key.
- deleted 11y ago
  [deleted]
sarciszewski 11y ago
Item number 1: SSL is obsolete, use TLS. 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.)
- adrtessier 11y ago
  Seriously. I can understand non-engineering-types calling SSL "SSL" still, but there's a point at which I will begin to date or discredit people's knowledge of "SSL" if they're still referring to it as such (and not to one of the libraries like polar, open, boring, etc.) 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. Most people don't call WPA WEP anymore.
  - agwa 11y ago
    > 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-changes-in.html http://tim.dierks.org/2014/05/security-standards-and-name-ch...
  - geofft 11y ago
    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.
    - ricksplat 11y ago
      WPA/WPA2 is a very good analogy for SSL/TLS. Effectively the same protocol, but a more rigorously defined standard. In the case of WPA2 it was WPA as ratified by IEEE 802.11i, whereas the original WPA had to be rushed out to answer the immediate deficiencies in WEP.
- scrollaway 11y ago
  > try to move forward with the correct acronym? This won't happen as long as OpenSSL (or libressl) is popular.
  - marcosdumay 11y ago
    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.
    - mikemaccana 11y ago
      libtls is part of libressl: http://www.libressl.org/ http://www.libressl.org/ > LibreSSL is composed of four parts: > The openssl(1) utility, which provides tools for managing keys, certificates, etc. > libcrypto: a library of cryptography fundamentals > libssl: a TLS library, backwards-compatible with OpenSSL > libtls: a new TLS library, designed to make it easier to write foolproof applications
- draw_down 11y ago
  It's difficult to understand the difference, especially when people use the terms interchangeably.
  - geofft 11y ago
    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.
  - sarciszewski 11y ago
    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.
    - draw_down 11y ago
      Fantastic.
- yuhong 11y ago
  As a side note, using SSL to just refer to SSLv2 and SSLv3 is a misnomer. SSLv2 and SSLv3 are completely different protocols.
- nailer 11y ago
  Yep, and people mean 'host name' rather than 'domain name'. But web developers don't care and use the terms interchangably, infosec people know SSL was rebranded into TLS by Microsoft, and none of these things are important since everyone knows what you're talking about and being pedantic would distract from your actual message.
daok 11y ago
Right from the beginning "EV cert". What is EV? When you write article and it's the first time you use acronym, please define it.
- jbhatab 11y ago
  Yeah I have no clue what that is.
  - manachar 11y ago
    Extended Validation. Usually implies the certificate authority has gone through extra steps to verify the identity of the domain owner.
- deleted 11y ago
  [deleted]
- TazeTSchnitzel 11y ago
  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.
  - frik 11y ago
    Somewhere I read that EV certs (green bar) are slower because of an additional round trip or so. If it is the case, can someone point me to an article that explains this?
    - 11y ago
paulschreiber 11y ago
I've compiled lots of resources for moving to HTTPS: https://docs.google.com/document/d/1EJKAoa4Hxc4AyH0znuA_AAplcNeNejEhATFptFX-OME/edit https://docs.google.com/document/d/1EJKAoa4Hxc4AyH0znuA_AApl...
TazeTSchnitzel 11y ago
Another thing: You should probably go TLS-only. Set up a 301 redirect from HTTP to HTTPS, and set the Strict-Transport-Security header on all HTTPS responses. 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/792986d18d8583712fa3fe59d0ec047b21701d46 https://github.com/TazeTSchnitzel/blog/commit/792986d18d8583...
- geofft 11y ago
  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.
gcb0 11y ago
beware of item 4. Android 2.3 is still prevalent in some markets
- fredrik-j 11y ago
  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.
  - hsivonen 11y ago
    Chrome for Android 42 and older requires Android 4.0 or newer. Current versions require 4.1 or newer. What you say about Firefox is accurate, though.
geofft 11y ago
A slightly stronger argument not to use 4096-bit certs is that just about every (intermediate) CA certificate out there is 2048-bit, and there's no security advantage to your cert being 4096-bit if it only has a 2048-bit signature. An attacker can just factor your CA's public key and not care how strong your own public key is. So it's not just that it slows down your site, it slows down your site without any additional security or other benefit.
- mikemaccana 11y ago
  That's an excellent point - I've added it to the article and credited you.
jzd 11y ago
The general public couldn't care less about EV certs. Important reading: http://webmasters.stackexchange.com/a/9095 http://webmasters.stackexchange.com/a/9095
- deleted 11y ago
  [deleted]
james-skemp 11y ago
You might be slow from traffic, but just in case that's not the case, the linked article loads fine but the home page does not on a 2nd gen Nexus 7. I see the top navigation followed by a white page, no scrollbar.
- nailer 11y ago
  What browser are you using on the Nexus 7? We test on current Chrome (which I imagine most Nexus 7 users are using).
angry-hacker 11y ago
My addition: if you use SNI cert, expect loads of problems. And I don't mean browser support. 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.
- marcosdumay 11y ago
  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.
  - angry-hacker 11y ago
    Yeah, I suspect it's because of Python 2.7.9 So many things are broken because of it. It doesn't have native SNI capability.
- discreditable 11y ago
  > 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.
  - angry-hacker 11y ago
    What's the url of your site, if not a secret? Maybe you're lucky your site is being crawled by the "newer"/updated bots that have SNI capabilities.
    - discreditable 11y ago
      I have no idea, but Bing is indexing away! https://www.bing.com/search?q=site%3Abrashear.me https://www.bing.com/search?q=site%3Abrashear.me
      - 11y ago
leni536 11y ago
What should I know about cert revocation and client support for it?
theandrewbailey 11y ago
Re: Point 1 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=theandrewbailey.com 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.jks
Swannie 11y ago
A good start. If you want to improve it, please add information about how to consume HTTPS services in a secure way. Also 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 :-)

222 points by mikemaccana 11y ago

A less common question we get, that a lot of web devs are interested in is 'How do I mitigate against MITM attacks'. - 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-trusts 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 https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) which throws up a browser warning if someone accesses your site with a new key.

deleted 11y ago
[deleted]

sarciszewski 11y ago

Item number 1: SSL is obsolete, use TLS. 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.)

adrtessier 11y ago
Seriously. I can understand non-engineering-types calling SSL "SSL" still, but there's a point at which I will begin to date or discredit people's knowledge of "SSL" if they're still referring to it as such (and not to one of the libraries like polar, open, boring, etc.) 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. Most people don't call WPA WEP anymore.
- agwa 11y ago
  > 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-changes-in.html http://tim.dierks.org/2014/05/security-standards-and-name-ch...
- geofft 11y ago
  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.
  - ricksplat 11y ago
    WPA/WPA2 is a very good analogy for SSL/TLS. Effectively the same protocol, but a more rigorously defined standard. In the case of WPA2 it was WPA as ratified by IEEE 802.11i, whereas the original WPA had to be rushed out to answer the immediate deficiencies in WEP.
scrollaway 11y ago
> try to move forward with the correct acronym? This won't happen as long as OpenSSL (or libressl) is popular.
- marcosdumay 11y ago
  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.
  - mikemaccana 11y ago
    libtls is part of libressl: http://www.libressl.org/ http://www.libressl.org/ > LibreSSL is composed of four parts: > The openssl(1) utility, which provides tools for managing keys, certificates, etc. > libcrypto: a library of cryptography fundamentals > libssl: a TLS library, backwards-compatible with OpenSSL > libtls: a new TLS library, designed to make it easier to write foolproof applications
draw_down 11y ago
It's difficult to understand the difference, especially when people use the terms interchangeably.
- geofft 11y ago
  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.
- sarciszewski 11y ago
  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.
  - draw_down 11y ago
    Fantastic.
yuhong 11y ago
As a side note, using SSL to just refer to SSLv2 and SSLv3 is a misnomer. SSLv2 and SSLv3 are completely different protocols.
nailer 11y ago
Yep, and people mean 'host name' rather than 'domain name'. But web developers don't care and use the terms interchangably, infosec people know SSL was rebranded into TLS by Microsoft, and none of these things are important since everyone knows what you're talking about and being pedantic would distract from your actual message.

daok 11y ago

Right from the beginning "EV cert". What is EV? When you write article and it's the first time you use acronym, please define it.

jbhatab 11y ago
Yeah I have no clue what that is.
- manachar 11y ago
  Extended Validation. Usually implies the certificate authority has gone through extra steps to verify the identity of the domain owner.
deleted 11y ago
[deleted]
TazeTSchnitzel 11y ago
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.
- frik 11y ago
  Somewhere I read that EV certs (green bar) are slower because of an additional round trip or so. If it is the case, can someone point me to an article that explains this?
  - 11y ago

paulschreiber 11y ago

I've compiled lots of resources for moving to HTTPS: https://docs.google.com/document/d/1EJKAoa4Hxc4AyH0znuA_AAplcNeNejEhATFptFX-OME/edit https://docs.google.com/document/d/1EJKAoa4Hxc4AyH0znuA_AApl...

TazeTSchnitzel 11y ago

Another thing: You should probably go TLS-only. Set up a 301 redirect from HTTP to HTTPS, and set the Strict-Transport-Security header on all HTTPS responses. 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/792986d18d8583712fa3fe59d0ec047b21701d46 https://github.com/TazeTSchnitzel/blog/commit/792986d18d8583...

geofft 11y ago
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.

gcb0 11y ago

beware of item 4. Android 2.3 is still prevalent in some markets

fredrik-j 11y ago
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.
- hsivonen 11y ago
  Chrome for Android 42 and older requires Android 4.0 or newer. Current versions require 4.1 or newer. What you say about Firefox is accurate, though.

geofft 11y ago

A slightly stronger argument not to use 4096-bit certs is that just about every (intermediate) CA certificate out there is 2048-bit, and there's no security advantage to your cert being 4096-bit if it only has a 2048-bit signature. An attacker can just factor your CA's public key and not care how strong your own public key is. So it's not just that it slows down your site, it slows down your site without any additional security or other benefit.

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

jzd 11y ago

The general public couldn't care less about EV certs. Important reading: http://webmasters.stackexchange.com/a/9095 http://webmasters.stackexchange.com/a/9095

deleted 11y ago
[deleted]

james-skemp 11y ago

You might be slow from traffic, but just in case that's not the case, the linked article loads fine but the home page does not on a 2nd gen Nexus 7. I see the top navigation followed by a white page, no scrollbar.

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

angry-hacker 11y ago

My addition: if you use SNI cert, expect loads of problems. And I don't mean browser support. 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.

marcosdumay 11y ago
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.
- angry-hacker 11y ago
  Yeah, I suspect it's because of Python 2.7.9 So many things are broken because of it. It doesn't have native SNI capability.
discreditable 11y ago
> 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.
- angry-hacker 11y ago
  What's the url of your site, if not a secret? Maybe you're lucky your site is being crawled by the "newer"/updated bots that have SNI capabilities.
  - discreditable 11y ago
    I have no idea, but Bing is indexing away! https://www.bing.com/search?q=site%3Abrashear.me https://www.bing.com/search?q=site%3Abrashear.me
    - 11y ago

leni536 11y ago

What should I know about cert revocation and client support for it?

theandrewbailey 11y ago

Re: Point 1 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=theandrewbailey.com 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.jks

Swannie 11y ago

A good start. If you want to improve it, please add information about how to consume HTTPS services in a secure way. Also 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 :-)