---
title: TLS & Certificate Challenges
published: 2017-02-26
---

As a response to 
[this](http://blog.xot.nl/2017/02/26/fix-tls-lets-get-rid-of-certificates/) 
post about ditching certificates in TLS, I thought of some other approaches 
that may improve the situation for the user when dealing with phishing on the 
"modern" web. I also posted a comment there, but will expand a bit on that 
here.

A possible alternative, without getting rid of certificates right away, could 
be to reduce the possibility of users being phished using current deployed 
technology with some (minor) changes. Although, getting rid of 
[X.509](https://en.wikipedia.org/wiki/X.509), and 
[ASN.1](https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One), would be a 
way to greatly reduce the attack surface by and of itself. Also the number of 
(semi) trusted CAs part of browsers is staggering.

### Reduce number of CAs

A possibly way towards getting more control over trust in the CA system, may 
be to greatly reduce the number of CA certificates in the browsers. Ideally 
it'd be restricted to a handful of CAs.

For [DV](https://en.wikipedia.org/wiki/Domain-validated_certificate) a limit 
number of CAs could be used, after all, if certificates are free, and so is the
tooling, maybe we only need a few, maybe only 
[Let's Encrypt](https://letsencrypt.org/).

The rest of the CAs would only provide 
[EV](https://en.wikipedia.org/wiki/Extended_Validation_Certificate) 
certificates. It would be great to have less than 20 CAs in your browser that 
have no ability to create sub CAs and must provide a complete 
[CT](https://en.wikipedia.org/wiki/Certificate_Transparency) log.

### Restrict the CAs

Furthermore, a CA could be tied to a (subset) of possible 
[(cc)TLDs](https://en.wikipedia.org/wiki/Country_code_top-level_domain) to sign
using some kind of X.509 extension. For example only European CAs can sign 
EV certificates for `.nl` or `.de` domains, but they would be unable to do so 
for `.us`.

### Browser Trust Levels

This way, different browser capabilities depending on the level of trust. For 
example, HTTP only would completely disable JavaScript, cookies and not even 
allow `<form>` submits. A DV certificate would allow "normal" operation, but 
block things like submitting credit card numbers or SSNs. Having an EV 
certificate would remove those restrictions.

Of course these suggestions could be implemented and rolled out in addition to 
each other, [TOFU](https://en.wikipedia.org/wiki/Trust_on_first_use) and for 
example 
[DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) 
with 
[DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) 
and we'd eventually settle on a mix of solutions where ideally the user is more 
safe from phishing and the attack surface of the technology will be 
substantially reduced.