add tls_challenges post

1 files changed, 62 insertions, 0 deletions

diff --git a/posts/tls_challenges.md b/posts/tls_challenges.md
new file mode 100644
index 0000000..178323c
--- /dev/null
+++ b/posts/tls_challenges.md
@@ -0,0 +1,62 @@
+---
+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.