Alice Wonder Miscreations
Established Member
- Impact
- 177
The PKI system has a problem, namely that it is too easy to get a CA (Certificate Authority) signed TLS certificate fraudulently, there have been numerous cases where they are issued to people they should not have been issued to. The problem is that there are way too many certificate authorities that your browser trusts.
With a fraudulently signed TLS certificate that claims to be from example [dot] com, a MITM attack can be pulled off against users trying to visit example [dot] com and their browser will accept it.
Certificate Pinning is a method of adding a verification process to the certificate sent to the browser. The browser can verify that the certificate is both signed and matches the fingerprint of what it suppose to be for that specific website, making MITM attacks that much more difficult.
DNSSEC + TLSA (aka DANE)
TLSA is a DNS resource type that can be used for TLS certificate pinning. It provides a fingerprint to the specific port (e.g. 443), protocol (e.g. tcp), and hostname. As DNS itself is not very secure, TLSA is not very beneficial unless the DNS records are signed with DNSSEC and the client is able to validate DNSSEC responses.
At this point in time, no mainstream browsers natively support DNSSEC even though the root DNS server has been signed since 2010 and most TLDs are DNSSEC signed. There are add-ons that support it, but the add-ons themselves can cause the browser to be very slow if the DNS resolver blocks DNSSEC requests which unfortunately some do.
The way it basically works, the browser does a DNS request for a TLSA record on the port, protocol, and FQDN. I believe most only do this when the zone is DNSSEC signed, there's not much point in making the request when it isn't.
If the service has TLSA, one or more responses will be sent to the browser and those responses can be validated via DNSSEC.
Then when the client requests the TLS certificate from the server, it can validate that the fingerprint matches one of the TLSA records and refuse to connect if it doesn't.
The downsides is that three things are required for this to work:
HPKP
This is a different approach. Instead of using DNS to pin the certificate, an HTTP header sends the fingerprint to the browser.
Several browsers already support it, but this is a flawed approach from the start.
First of all it is very specific to HTTPS, HPKP doesn't work with other ports and protocols that other services are using because it is served in a HTTP header. So for other TLS related services, you have to use a different pinning method even in cases where the same signed certificate is used.
HPKP is only of value at preventing a MITM attack if the client already has the correct fingerprint before the MITM starts. Otherwise with the attacker between the server and client, the attacker is free to modify the header sent by the server or even discard it.
So HPKP is useless when an attack is taking place and the client doesn't already have the fingerprint from a previous visit to the website.
Due to the fact that HPKP is useless if the client doesn't already have the fingerprint before the attack begins, setting the age of how long the browser is to store the fingerprint to something short makes it useless. You have to instruct the client to save it for a fairly long time period to maximize its usefulness. 2 months is fairly standard.
A long age though creates another problem. If your certificate is compromised and you need to revoke it and use a different one, then clients will have the fingerprint of the compromised certificate for the life of the long age. This allows an attacker who has the compromised certificate to use it for a MITM against clients that still have it stored, and it means you have to have a backup already pinned and so that when you switch certificates, the fingerprint will already be in what clients have stored.
That has to be done for each server, the private key for the backup should not be on the web server until it needed, and it adds to complexity.
Personally I think HPKP can be dangerous because an attacker who does compromised your private key has a definite window where they can continue using that compromised certificate on clients that stored the fingerprint, and the attacker can even send a header of their own including fingerprints of fraudulent certs that haven't been revoked allowing their MITM to continue.
------
For the time being, HPKP is what is browsers are most likely to support (though some don't) so despite its flaws, for MITM mitigation it probably should be used.
However it is my hope that browsers will start to support DNSSEC, more resolvers will support it (or at least not block it, who the frack do ISPs think they are to block valid DNS requests?), and more zones will be DNSSEC signed.
Because from a technical point of view, TLSA is a much more secure way to pin a TLS x509 certificate and mitigate MITM.
Thoughts?
With a fraudulently signed TLS certificate that claims to be from example [dot] com, a MITM attack can be pulled off against users trying to visit example [dot] com and their browser will accept it.
Certificate Pinning is a method of adding a verification process to the certificate sent to the browser. The browser can verify that the certificate is both signed and matches the fingerprint of what it suppose to be for that specific website, making MITM attacks that much more difficult.
DNSSEC + TLSA (aka DANE)
TLSA is a DNS resource type that can be used for TLS certificate pinning. It provides a fingerprint to the specific port (e.g. 443), protocol (e.g. tcp), and hostname. As DNS itself is not very secure, TLSA is not very beneficial unless the DNS records are signed with DNSSEC and the client is able to validate DNSSEC responses.
At this point in time, no mainstream browsers natively support DNSSEC even though the root DNS server has been signed since 2010 and most TLDs are DNSSEC signed. There are add-ons that support it, but the add-ons themselves can cause the browser to be very slow if the DNS resolver blocks DNSSEC requests which unfortunately some do.
The way it basically works, the browser does a DNS request for a TLSA record on the port, protocol, and FQDN. I believe most only do this when the zone is DNSSEC signed, there's not much point in making the request when it isn't.
If the service has TLSA, one or more responses will be sent to the browser and those responses can be validated via DNSSEC.
Then when the client requests the TLS certificate from the server, it can validate that the fingerprint matches one of the TLSA records and refuse to connect if it doesn't.
The downsides is that three things are required for this to work:
- The zone has to be DNSSEC signed, not very common right now.
- The resolver has to allow DNSSEC queries. Some don't.
- The client has to support DNSSEC + TLSA. Most don't.
HPKP
This is a different approach. Instead of using DNS to pin the certificate, an HTTP header sends the fingerprint to the browser.
Several browsers already support it, but this is a flawed approach from the start.
First of all it is very specific to HTTPS, HPKP doesn't work with other ports and protocols that other services are using because it is served in a HTTP header. So for other TLS related services, you have to use a different pinning method even in cases where the same signed certificate is used.
HPKP is only of value at preventing a MITM attack if the client already has the correct fingerprint before the MITM starts. Otherwise with the attacker between the server and client, the attacker is free to modify the header sent by the server or even discard it.
So HPKP is useless when an attack is taking place and the client doesn't already have the fingerprint from a previous visit to the website.
Due to the fact that HPKP is useless if the client doesn't already have the fingerprint before the attack begins, setting the age of how long the browser is to store the fingerprint to something short makes it useless. You have to instruct the client to save it for a fairly long time period to maximize its usefulness. 2 months is fairly standard.
A long age though creates another problem. If your certificate is compromised and you need to revoke it and use a different one, then clients will have the fingerprint of the compromised certificate for the life of the long age. This allows an attacker who has the compromised certificate to use it for a MITM against clients that still have it stored, and it means you have to have a backup already pinned and so that when you switch certificates, the fingerprint will already be in what clients have stored.
That has to be done for each server, the private key for the backup should not be on the web server until it needed, and it adds to complexity.
Personally I think HPKP can be dangerous because an attacker who does compromised your private key has a definite window where they can continue using that compromised certificate on clients that stored the fingerprint, and the attacker can even send a header of their own including fingerprints of fraudulent certs that haven't been revoked allowing their MITM to continue.
------
For the time being, HPKP is what is browsers are most likely to support (though some don't) so despite its flaws, for MITM mitigation it probably should be used.
However it is my hope that browsers will start to support DNSSEC, more resolvers will support it (or at least not block it, who the frack do ISPs think they are to block valid DNS requests?), and more zones will be DNSSEC signed.
Because from a technical point of view, TLSA is a much more secure way to pin a TLS x509 certificate and mitigate MITM.
Thoughts?
Last edited:
