SSL considered bloated • Hacker News Board

Re: SSL considered bloated

#41

Post by zeveb » Tue, Sep 06, 2016, 3:09 PM UTC

In my perfect world, you'd receive a certificate from your ISP when it assigns you one of the IP addresses it was itself assigned, and you'd receive a certificate from your registrar when you purchase a domain name. The former certificate would be good for the duration of your IP assignment; the latter for the duration of your domain ownership.

The IP-level certificate would be used for IPsec; the DNS-level certificate would be used for HTTP and other protocols; if you needed some other, stronger sort of identity verification then you'd need to take other measures.

This would solve the accessibility problem.

As for proxying, I think that HTTP had a really interesting idea with proxying, but it just doesn't work in practice. Proxies are untrustworthy, so it doesn't make sense to use them.

As for speed, I don't think SSL is noticeably slow from a modern phone.

Re: SSL considered bloated

#42

Post by zeveb » Tue, Sep 06, 2016, 3:11 PM UTC

watwatwatwat wrote: post #26

CiPHPerCoder wrote: post #6

> Seems to me a bit like equipping everyone with armour to make shooting them more difficult. Solving the problem the wrong way? I don't know, making humans immune to bullets would be an elegant solution to the gun control debate which doesn't involve disagreements over the second amendment, and would make everyone win.

Just move to autralia/europe.

> Just move to autralia/europe.

Being in Europe doesn't seem to have helped the editors of Charlie Hebdo …

Re: SSL considered bloated

#43

Post by tangent128 » Tue, Sep 06, 2016, 3:20 PM UTC

atemerev wrote: post #40

The problem with SSL/TLS is that it is binary. There's currently very strong pro-binary movement in the ranks of Internet infrastructure engineers, probably originated in Google. Yes, binary protocols are marginally more efficient, but they are inherently harder to understand, debug, and generally see what's happening, especially in high-stress conditions when something fails in production. Binary protocols are more…

Text-based protocols are simple for humans to read, but anything requiring parsing is a security smell.

Even if you are sure your buffer handling is free of bugs (reasonable in new languages, but the known-size of binary fields has been a security strength for them), the ambiguity of text is dangerous.

Interpreting as text easily corrupts binary embeds if you aren't careful, and escaping bloats the size of what's already the largest part of your message.

Many security bugs have been triggered by implementations disagreeing about when they interpret UTF-8 and when they don't. UTF-8-encoded ASCII characters, for example, may cause one parser to recognize a keyword that another ignores; nevermind different sets of accepted whitespace characters.

You could define a very-strict encoding and delimination scheme, but at that point you can't trust text editors to edit it- making it effectively a needlessly-complicated binary protocol.

Re: SSL considered bloated

#44

Post by tlsfan » Tue, Sep 06, 2016, 3:26 PM UTC

The author lists legitmate motivations for why people want to see 100% SSL adoption.

The CA system also began with such good intentions. But motivations for profit enveloped good intentions. Certificates became a business, and the quality of the software became an afterthought.

The same may be or is happening with SSL/TLS deployment. With a function such as encryption, one cannot ignore software quality. Poor quality can defeat the whole purpose of the software. There is no point in using bad encryption software.

One of the good intentions the author cites is that people want ubiquitous encryption. Is encryption synonymous with SSL? Why? SSL is not the only system ever written to encrypt internet traffic. And it is probably far from the best one that could be written.

Nothing wrong with the good intentions. But is SSL is an asset or a liability? There is a cost to taking on SSL's baggage of complexity and maybe it's only worth it if the benefit achieved is real and not illusory.

If SSL can so easily be exploited, then the false sense of security it's name inspires may cause more problems than SSL solves. But that's only for users. Others with purely commmercial goals stand to profit immensely from SSL adoption, the same way businesses did from CA certificates.

SSL was not created with the intent to protect non-commercial communications. It was created in the 1990's by Mozilla to allow for "e-commerce" using their Netscape browser. It served it purpose.

SSL is old and people are attempting to retrofit it with "improvements". Such as being able to host multiple sites with one wildcard certificate on one IP address. This is a hack. It's called SNI and it breaks a lot of software. People should consider why such a "feature" even needs to be implemented. Is it for the benefit of the user? The CA business has become nothing more than an impediment for many people.

Costs vs benefits. Not just for business but for users.

Re: SSL considered bloated

#45

Post by atemerev » Tue, Sep 06, 2016, 3:39 PM UTC

tangent128 wrote: post #43

atemerev wrote: post #40

The problem with SSL/TLS is that it is binary. There's currently very strong pro-binary movement in the ranks of Internet infrastructure engineers, probably originated in Google. Yes, binary protocols are marginally more efficient, but they are inherently harder to understand, debug, and generally see what's happening, especially in high-stress conditions when something fails in production. Binary protocols are more…

Text-based protocols are simple for humans to read, but anything requiring parsing is a security smell. Even if you are sure your buffer handling is free of bugs (reasonable in new languages, but the known-size of binary fields has been a security strength for them), the ambiguity of text is dangerous. Interpreting as text easily corrupts binary embeds if you aren't careful, and escaping bloats the size of what's alr…

Well, OpenPGP works, and it is not terribly complicated. But yes, UTF-8 is a huge can of worms.

(An accepted solution for this problem is obligatory "canonicalization" step - transforming the message into agreed canonical format before transmitting it. Still viewable and editable by text editors, no need to worry about parsing errors. Canonicalization step can still be error-prone, but the attack surface is much less than every possible parser in the world.)

Re: SSL considered bloated

#46

Post by spacemanmatt » Tue, Sep 06, 2016, 3:39 PM UTC

king_magic wrote: post #18

I really hope I'm not the only person who mentally groans whenever I see yet another "X considered Y" clickbait title. It's the tech equivalent of "this one weird trick" or "X Happened And You Won't Believe What Happened Next".

Worthless memetic content considered harmful. Hope that helps... :)

Re: SSL considered bloated

#47

Post by zokier » Tue, Sep 06, 2016, 3:40 PM UTC

tangent128 wrote: post #43

atemerev wrote: post #40

The problem with SSL/TLS is that it is binary. There's currently very strong pro-binary movement in the ranks of Internet infrastructure engineers, probably originated in Google. Yes, binary protocols are marginally more efficient, but they are inherently harder to understand, debug, and generally see what's happening, especially in high-stress conditions when something fails in production. Binary protocols are more…

Text-based protocols are simple for humans to read, but anything requiring parsing is a security smell. Even if you are sure your buffer handling is free of bugs (reasonable in new languages, but the known-size of binary fields has been a security strength for them), the ambiguity of text is dangerous. Interpreting as text easily corrupts binary embeds if you aren't careful, and escaping bloats the size of what's alr…

> Text-based protocols are simple for humans to read, but anything requiring parsing is a security smell.

Any protocol requires parsing, binary or not.

Re: SSL considered bloated

#48

Post by spacemanmatt » Tue, Sep 06, 2016, 3:40 PM UTC

CiPHPerCoder wrote: post #6

> Seems to me a bit like equipping everyone with armour to make shooting them more difficult. Solving the problem the wrong way? I don't know, making humans immune to bullets would be an elegant solution to the gun control debate which doesn't involve disagreements over the second amendment, and would make everyone win.

I should have known the gun debate could be reframed in terms of supply-side vs demand-side economics...

Re: SSL considered bloated

#49

Post by gant » Tue, Sep 06, 2016, 3:45 PM UTC

marcosdumay wrote: post #30

I was really expecting a serious discussion about useless and dangerous flags, outdated encryption, expensive and dangerous renegotiations... I got a one line complaint about "network traffic" (take a read about latency and bandwidth difference!), caching, and bad tooling (go learn some better tooling, it's out there). There are plenty of things to complain about in TLS, but the article touches none of them. What a b…

I'm personally still trying to figure out where the hordes of new users that just install Apache are. In these times, if you can install Apache 2 on a computer permanently connected to the internet you can probably also install Caddy or Certbot.

Re: SSL considered bloated

#50

Post by atemerev » Tue, Sep 06, 2016, 3:45 PM UTC

tangent128 wrote: post #43

atemerev wrote: post #40

The problem with SSL/TLS is that it is binary. There's currently very strong pro-binary movement in the ranks of Internet infrastructure engineers, probably originated in Google. Yes, binary protocols are marginally more efficient, but they are inherently harder to understand, debug, and generally see what's happening, especially in high-stress conditions when something fails in production. Binary protocols are more…

Text-based protocols are simple for humans to read, but anything requiring parsing is a security smell. Even if you are sure your buffer handling is free of bugs (reasonable in new languages, but the known-size of binary fields has been a security strength for them), the ambiguity of text is dangerous. Interpreting as text easily corrupts binary embeds if you aren't careful, and escaping bloats the size of what's alr…

Also, some sort of "parsing" (normalizing) is always required even for binary messages. Endianness, alignment conventions, etc. — just mapping the network bytes onto memory is inviting trouble.

(btw, network byte order is big-endian).