aboutsummaryrefslogtreecommitdiffstats
path: root/posts
diff options
context:
space:
mode:
authorFran├žois Kooman <fkooman@tuxed.net>2017-02-26 20:16:08 +0100
committerFran├žois Kooman <fkooman@tuxed.net>2017-02-26 20:16:08 +0100
commit9e60ba02214c8bc28423d74295408f523072245c (patch)
tree68876d4a0e2b45c009fe7109e9f9f141d3275c62 /posts
parentc3a26aaaba88cf2a9f587a2872967807168776de (diff)
downloadwww.tuxed.net-9e60ba02214c8bc28423d74295408f523072245c.zip
www.tuxed.net-9e60ba02214c8bc28423d74295408f523072245c.tar.gz
www.tuxed.net-9e60ba02214c8bc28423d74295408f523072245c.tar.xz
add tls_challenges post
Diffstat (limited to 'posts')
-rw-r--r--posts/tls_challenges.md62
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.