To give you a summarizing read over the Christmas days and not focusing on upcoming attacks, this post will try to give a high-level overview on the proposals for strengthening SSL/TLS PKI security, beyond promising that hacking certificates is in vain... The post is meant to be an open discussion on the advantages and disadvantages of the proposals, as well as on the correctness of my understanding. So please, please, please leave a comment if I got something wrong or some essential details are missing - and I am pretty sure something's missing or incorrect. I am trying to give a high-level overview without any technical depth, just to show the essence of the draft(s) (and hopefully understood the proposals correctly).
Decentraliezd SSL Observatory
To put it in a nutshell, a decentralized instance - e.g. the SSL Oberservatory - collects certificates. The client compares the certificate received from the target server with the one collected by the observatory. If the certificates differ, there is a high probability that one of both parties was fooled by an attacker. The disadvantage is that it remains unknown which one of both parties was fooled. Another disadvantage is the lack for privacy. If the client checks every certificate the Observatory can reconstruct the client's browsing behaviour. A single Observatory would also cause a single point of failure.
Perspectives
The idea of the decentralized Observatory is improved by the Perspectives approach. Here, different Trusted Notaries take the Observatory's part and additionally maintain a history of present and past certificates/keys to provide different perspectives. Instead of responding with just a single certificate the Trusted Notaries send the target's history. To facilitate the decision which party was subject of an attack the client asks a bunch of Notaries and compares the results. An attack must concern all Notaries to remain undetected. A major problem is caused by requesting the history of multiple Notaries - latency. Additionally, all Notaries must ideally be synchronized at the same time to provide an equal, common view on the web. Further on, the issue of privacy remains unsolved. Another problem is raised in case the notaries are add odds with each other or provide discordant perspectives or aren't accessible at all.
Convergence
Convergence is based on the Perspectives proposal and introduces a Proxy Notary to weaken the privacy issue and preserve some privacy. The Notaries are only contacted by the Proxy Notary and not directly by the User Agent. Of course, this only eases the problem if the user trusts the Proxy Notary. At the same time the single point of failure is reintroduced and the latency problem remains unsolved.
MECAI (Mutually Endorsing CA Infrastructure)
MECAI is based on the idea of different Voucher Authorities bailing/vouching for a target server. The User Agent keeps its privacy, because the target server is required to collect the necessary vouchers in advance and present them to the client. Once again, problems can be caused by differing views and unaccessability or poor performance. Latency...
DANE (DNS-Based Authentication of Named Entities)
This proposal is very interesting, because it does not rely on different views, but is instead based on the DNS system. The idea is that each DNS server delivers not only the IP belonging to the domain name, but additionally includes the expected certificate of the target server in the response. The whole trust relationship is transferred to the DNS system which distributes correct certificates. A User Agent can simply compare the certificate of the DNS response with the one sent by the target server during the SSL/TLS handshake. The proposal is especially interesting when combined with DNSSEC, but looks very inflexible at first view.
DNS Certification Authority Authorization (CAA) Resource Record
A quite similar concept is presented by the DNS CAA Resource Record proposal. Instead of sending the correct certificate, the DNS(-SEC) server responds with a list of CAs authorized to issue certificates for the target server. This is on the one hand a more flexible solution compared to fixed certificates, but on the other hand provides no protection if one of these CAs is compromised.
Certificate and Public Key Pinning
In this proposal the User Agent maintains a list of different CAs authorized to issue certificates for the target server. The certificate pinning of Google's Chrome browser for example, successfully helped detecting unauthorized certificates in the past. There are some variations of this concept - that's why I didn't add a link to the heading. In Chrome's case the pinned certificates are shipped with the browser. Other proposals recommend to pin each certificate on first use. While the first option is more secure, but as (in-)flexible as the current trusted Root CA concept, the second one introduces the problem that possibly certificates of an attacker are pinned (when the first connection is established to a rogue server). Additionally, revocation and renewing certificates can cause further issues.
Sovereign Keys
The Sovereign Keys project motivates for an additional key set, beyond the keys belonging to the certificate. These additional (Sovereign) Keys are used to sign the certificate of the target server. Monitoring Timeline Servers keep track of these Sovereign Keys. The User Agent requests the Sovereign Key for a target server from the Timeline Servers and checks if the additional signature of the certificate is correct. With this concept renewing or revoking certificates is independent from the trusted instances. Only the Sovereign Key has to be communicated to the Timeline Servers. A major drawback is the privacy issue (multiple request to ensure correctness of the Sovereign Key) - the client unveils its browsing behaviour to multiple parties.
Certificate Transparency
Certificate Transparency is a proposal by Google which combines the advantages of different proposals. The target server is responsible for obtaining signed timestamps issued by Certificate Logs which attest correctness of the certificate. These signed timestamps are bound to the target server's certificate. The Certificate Logs maintain appendable-only lists of certificates and can thus attest if a target server is using the correct certificate. Due to the appendable-only lists duplicate certificates can easily be detected. An independent set of Monitors and Auditors continuously ensure integrity and correctness of the Certificate Logs. An obvious problem is the first registration of the certificate which is ideally done by the issuing CA directly after issuance. If a wrong certificate is placed in a Certificate Log the concept is of no help until the certificate is successfully revoked, the signed timestamps expired and all Certificate Logs have been synchronized.
TACK (Trust Assertions for Certificate Keys)
TACK seems to be very similar to the Sovereign Keys proposal - it can be seen as some sort of dynamic Pinning of Sovereign Keys. Independent TACK Key pairs are introduced which are delivered during the SSL/TLS handshake (sure, only the public part). The certificates additionally carry the TACK Public key, a signature of the hostname and the certificate public key ( the TACK Private Key is used for this signature). The User Agent stores the TACK Public Key at first use and links it to the target server. The additional signature is verified each time the certificate is received. The problem of rogue servers on first use remains. Once an invalid TACK Public Key is pinned by the User Agent the concept is broken - the legitimate target server is locked out and the rogue server gains additional trust (until the pin entry expires).
Summarizing the proposals
All proposals have in common that the user has at least to trust a third party attesting validity of the target server or that the user has to ensure a single, initial connection not to be compromised. Mostly, the misbehaviour of a trusted third party can be detected by comparing multiple views, pooling the risks. The greatest benefits are achieved by combining this pooling with the current approach of trusted Root-CAs stored in the browser and validating the certificates for validity and correctness. All proposals have advantages as well as disadvantages. It seems to be an exciting and interesting ongoing development with an unclear outcome which proposal will in the end win the race.
Finally, merry Christmas to all of you - enjoy some calm days! Once again, please tell me if I got something wrong or if you spotted errors, have comments or simply want to highlight additional (dis-)advantages. For further reading please have a look at the documentation of each project or Hannes Tschofenig's summarizing internet draft at IETF on Web PKI Evolution.
Keine Kommentare:
Kommentar veröffentlichen