diff --git a/index.html b/index.html index 6d39632..d2b78b5 100644 --- a/index.html +++ b/index.html @@ -136,7 +136,6 @@ Ward Wouts
1. Addons 1. More - --- # SSL, TLS, what's in a name? --- @@ -158,6 +157,7 @@ layout: false ] .right-column[ Well, it's kind of a secure tunnel protocol over TCP. But it does not really fit into the OSI model. Which does not really fit with TCP/IP to begin with, so let's just not care and have a look. + ] ??? $ openssl s_client -connect www.nu.nl:443 @@ -190,9 +190,9 @@ SSL/TLS historically has two main purposes: - Protecting traffic using encryption. Both its confidentiality as its integrity. - Identifying the other side. This was what the lock in the browser URL bar used to be for, until it didn't make sense anymore. -Now, on a network you know and control completely there is no need for something like SSL/TLS. TCP can detect broken packets perfectly fine, so integrity is taken care of. There is noone snooping, because you are in control of the network and you already know what systems you are talking to: your own. +Now, on a network you know and control completely there is no need for something like SSL/TLS. TCP can detect broken packets perfectly fine, so integrity is taken care of. There is no one snooping, because you are in control of the network. No one else has access, and you already know what systems you are talking to: your own. -The internet is not such a network. +Such a network does not exist. - Snooping can easily be done by any network operator using listener ports on network equipment. - Traffic can be changed or diverted using a so called Man in the Middle attack @@ -224,7 +224,7 @@ layout: false ] .right-column[ To prevent a MitM attack, we need at least the following: -- a way to establish that we are starting the conversation with the right end-point +- a way to establish that we are starting the conversation with the right endpoint - a way to make sure the conversation cannot be hijacked The first problem is solved by using certificates. @@ -240,11 +240,13 @@ template: inverse ] .right-column[ A certificate is in essence the public part of a public private key pair. With a bunch of information tacked on, such as: -- web site the certificate is for -- issuer of the certificate +- website the certificate is for +- the name of the issuer of the certificate - signature by issuer for the certificate - ... much much more ] +??? +show certificate --- .left-column[ @@ -253,14 +255,16 @@ A certificate is in essence the public part of a public private key pair. With a .right-column[ So, how does a certificate get signed? -Or how does signing work in cryptography: -- take a message -- calculate a hash of the message -- encrypt the hash with your private key + +Or how does this signing work: +- take the unsigned certificate +- calculate a hash of the certificate +- encrypt the hash with the CAs private key + Now anyone can verify the signature by: -- decrypting it with your public key -- creating a hash of the message +- decrypting the signature with the CAs public key +- creating a hash of the website certificate - comparing the decrypted hash with the calculated hash Some variations on this scheme exist, but this is the gist. @@ -272,7 +276,7 @@ Some variations on this scheme exist, but this is the gist. .right-column[ This is where the whole model gets real ugly. -A certificate authority is a party that can sign certificates in such a way that the browser can verify them. +A certificate authority is a party that is trusted to sign certificates. The certificates of a certificate authority are, in the end, signed by root certificates. @@ -293,7 +297,7 @@ Or how to get to a state where an attacker that can watch all traffic, including This is where the client and server decide on: - Which version of TLS/SSL to use - Decide on which encryption (cipher suite) to use -- Establish the identity of the server using its certificate (and optionaly the client) +- Establish the identity of the server using its certificate (and optionally a client certificate) - Calculate a session key for the symmetric encryption following the handshake ] @@ -331,6 +335,8 @@ You've probably not encountered TLS1.3 a lot yet. It is a big improvement howeve - Arbitrary Diffie-Hellman groups: CVE-2016-0701 - Export ciphers: FREAK and LogJam attacks +As a consequence this makes forward secrecy mandatory in TLS1.3. + What's not to like? Well, that forward secrecy bit... It's great! But not everyone agrees. .footnote[See also: https://www.cloudflare.com/learning/ssl/why-use-tls-1.3/
@@ -355,45 +361,17 @@ template: inverse ## SNI ] .right-column[ -Traditionally only one certificate could be used for an HTTPS connection. As a consequence you need a dedicated IP address for each and every website using HTTPS. A solution was found in SNI (Server Name Indication). This is a mechanism where at the start of the handshake the connecting client specifies which servername it wants to connect to. Using SNI multiple websites can share on IP address and still use HTTPS connections. +Basically virtual hosting for TLS. -The obvious problem with the SNI approach is that the name is send at the start of the handshake, so before encryption starts. An observer can sniff this traffic an learn to which site the client wants to connect. This also allows for blocking sites on this level. To work around this blocking, domain fronting has been used: start a connection with requesting a non-blocked site (i.e. google). Then after establishing the connection (when the inner HTTP connection is established) request the name that is actually wanted (i.e. signal). +It changes the handshake slightly, so now in the first bit (the client helo) you can specify which hostname to connect to. + + + +] +??? +The obvious problem with the SNI approach is that the name is send at the start of the handshake, so before encryption starts. An observer can sniff this traffic and learn to which site the client wants to connect. This also allows for blocking sites on this level. To work around this blocking, domain fronting has been used: start a connection with requesting a non-blocked site (i.e. google). Then after establishing the connection (when the inner HTTP connection is established) request the name that is actually wanted (i.e. signal). Since mid 2018 ESNI (Encrypted SNI) is being rolled out, to solve the problems with SNI. -] ---- -.left-column[ -## DNS-Based Authentication of Named Entities (DANE) -] -.right-column[ -So certificate authorities are a misguided concept at best. Is there a better way? - -Well, actually: multiple. One of which is called DANE. DANE lets the owner of a domain certify the keys used by TLS by storing them in DNS. Which can be secured using DNSSEC. So, certificates without a CA being involved. - -Additionaly, it lets the domain owner specify which CA is allowed to sign these certificates. So we'd need to trust the certificate authorities a lot less. - -DANE is not used much, so this is mostly a theoretical fix. For obvious reasons CA's were against DANE. There is no support in Google Chrome, as DANE uses 1024-bit RSA, which Google want to eliminate from te browser. -] ---- -.left-column[ -## Let's encrypt -] -.right-column[ -Once upon a time certificates were expensive. Because of this reason only organisations that could afford them bought certificates. This gave the illusion that when a website had a certificate it was trustworthy. With dropping prices for certificates it became more and more evident that this trustworthyness was an illusion[*]. Let's encrypt shattered the illusion completely by makeing certificates free and automatically deployed (using the ACME protocol). This has caused a huge uptake of secure connections on the internet, which in general is regarded a good thing. - -.footnote[[*] In an attempt to keep the business model of certificates alive EV (Extended Validation) certificates were invented. In theory these certificate validate more than the site owner having a working creditcard.] -] ---- -.left-column[ -## Certificate pinning -] -.right-column[ -In some situations we can do better than the protocols by themselves allow for. The protocols are made for generic software, such as browsers, that needs to work with any site. But when you're making dedicated software, such as an app, you can implement more stringent checks of certificates. - -I.e. a banking app can check all information in a certificate, including the issuer. Often this is implemented mostly by string comparisons. Better is including the public root certificate of the issuer in the application. - -These kind of checks are called certificate pinning. -] --- .left-column[ ## HSTS @@ -417,6 +395,33 @@ The downside of this is, of course, that it gives Google more control than it sh .footnote[[*] https://hstspreload.org/] ] --- +.left-column[ +## Let's Encrypt +] +.right-column[ +Once upon a time certificates were expensive. Because of this reason only organisations that could afford them bought certificates. This gave the illusion that when a website had a certificate it was trustworthy. With dropping prices for certificates it became more and more evident that this trustworthyness was an illusion[*]. Let's Encrypt shattered the illusion completely by makeing certificates free and automatically deployed (using the ACME protocol). This has caused a huge uptake of secure connections on the internet, which in general is regarded a good thing. + +.footnote[[*] Diginotar was hacked by an Iranian and Iran was happily creating certificates on Diginotar's infrastructure.
+The same thing happened to Comodo, but they were too big to fail.
+Recently Symantic was banned for running an unsafe operation.
+In an attempt to keep the business model of certificates alive EV (Extended Validation) certificates were invented. In theory these certificate validate more than the site owner having a working creditcard.] +] +--- +.left-column[ +## DNS-Based Authentication of Named Entities (DANE) +] +.right-column[ +So certificate authorities are a misguided concept at best. Is there a better way? + +Well, actually: multiple. One of which is called DANE. DANE lets the owner of a domain certify the keys used by TLS by storing them in DNS. Which can be secured using DNSSEC. So, certificates without a CA being involved. + +Additionally, it lets the domain owner specify which CA is allowed to sign these certificates. So we'd need to trust the certificate authorities a lot less. + +DANE is not used much for HTTP, so this is mostly a theoretical fix. For obvious reasons CA's were against DANE. There is no native support in browsers. + +DANE is more often used for things like SMTP. +] +--- template: inverse # More? --- @@ -430,7 +435,7 @@ There is much much more that we could cover, but won't. Including but not limite - Certificate transparancy logs/monitors/auditors - ACME - CRLs -- HPKP +- Certificate pinning - ... ]