I just want to point out that TLS verification is extremely fast in HTTP2 to the point where speed is arguably a non-issue.
SSL considered bloated
51–60 of 60 posts
Re: SSL considered bloated
#52Somewhat related: I went to check something on my home router for the first time in months and learned that: a) it uses an old version of SSL to serve up its admin page b) all modern browsers refuse to load that page and no longer offer an override I had to dig up and load an old unpatched browser so I could turn off SSL completely on my router so I can continue to administer it. Am I more secure now? I'm not sure.
A better option would have been to use something like sslstrip/sslsplit/mitmproxy to strip/bump the SSL connection. Admittedly the situation is bit unfortunate, but there aren't really many good solutions when dealing with broken crypto.
Re: SSL considered bloated
#53The problem with this argument is that there are very high-security pages on the Internet --- things that protect people's bank accounts or most sensitive personal information --- and they're not going away. The junction, at the protocol level, between insecure web sites and secure ones is a major design weakness; we would have fewer attack vectors in the long run if we could count on uniform encryption across the we…
This is precisely my thought on SSL. I'm no expert (correct me if I'm wrong), but if I understand the technology correctly: if your http website connects to an https login page, who is to stop someone from spoofing a link to a fake login page on the http website.
This is an annoying problem – even if your entire site uses HTTPS, users could be vulnerable if they ever follow an HTTP link or their browser's autocomplete doesn't update to use HTTPS.
Strict Transport Security was designed to solve that problem partially by telling the browser to never make an insecure HTTP request:
http://caniuse.com/#feat=stricttransportsecurity
That's widely supported now but it does require your browser to have previously visited the legitimate site within the stored `max-age` period. Preloading (https://hstspreload.appspot.com/) can close that further but increases the organizational commitment that your web developers will never break the all-HTTPS contract by mistake.
Re: SSL considered bloated
#54Earlier quoted context omitted.
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).
Point, though binary normalization is easier to define in a manner everybody will consistently implement as opposed to, say, SMTP headers.
...I guess it's abominations like SMTP that I mainly think of when I hear "text-based protocol".
JSON and bencode are probably safe enough.
(Canonicalization is not useful from a security perspective, since an attacker is under no obligation to canonicalize their message.)
Re: SSL considered bloated
#55I 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".
What's clickbaitish about the title? If the article is aligned with title, then the title is fine.
clickbait (google search): "(on the Internet) content, especially that of a sensational or provocative nature, whose main purpose is to attract attention and draw visitors to a particular web page."
I think this safely fits under the sensational/provocative attention-grabbing umbrella.
Re: SSL considered bloated
#56As a compromise between SSL and plain http, wouldn't it be enough for most of the content to be signed? E.g. background images don't necessarily have to be encrypted. They can be sent in plain sight with a signature which ensures that the image hasn't been modified. The signature has to be computed only once so that the overhead can be neglected.
Re: SSL considered bloated
#57Re: SSL considered bloated
#58Earlier quoted context omitted.
EV certificates help.
EV certificates may improve a user's awareness of a spoofed page, but cannot do anything to make it more technically difficult to execute. Providing an HTTPS login with an otherwise HTTP site is vulnerable to redirection to HTTP or to another site. There is lots of evidence that suggests that in this configuration, cookies are often not set up properly (secure only) and can therefore be transmitted and stolen over HT…
> EV certificates may improve a user's awareness of a spoofed page, but cannot do anything to make it more technically difficult to execute.
This is what I meant, this is why I used "may". Obviously the user must know the details of how ssl works which is not many of them.
Re: SSL considered bloated
#59The problem with this argument is that there are very high-security pages on the Internet --- things that protect people's bank accounts or most sensitive personal information --- and they're not going away. The junction, at the protocol level, between insecure web sites and secure ones is a major design weakness; we would have fewer attack vectors in the long run if we could count on uniform encryption across the we…
Totally agree, encryption by default is the best option. However:
And if SSL is offered perhaps it should still be possible to access non-security-critical pages by plain old HTTP.
However, I'm not sure if this will open attack vectors for the unencrypted sites. I.e. I'd imagine that a man-in-the-middle-style attack could show the main site / URL (www.mydomain.tld) with another cert and just forward the un{encrypted,secure} content … but then again, this is not a new technique and can be prevented by public key pinning (though, https://news.ycombinator.com/item?id=12434585 :-/), DNSSEC/DANE (no browser vendor buy-in yet), etc.
Any idea if this were a sane idea for other sites as well? With enough momentum, browser vendors could detect and display un{encrypted,unsecure}. sub-domains specially.
Re: SSL considered bloated
#60SSL/TLS is bloated but that's not a reason not to use it. Rather it's a reason we need some TLSv2 that just removes the crap and focuses only on three encryption/authentication modes: * Desktop: High throughput, lots of CPU, minimal latency * IoT: small throughput, very little CPU, latency acceptable * Mobile: small to medium throughput, some CPU, minimize latency A lot of bloated protocols are still good, they're bl…
It seems to make more sense to just have ONE that can accommodate all those scenarios in a secure way. One doesn't solve bloat by introducing more bloat. I'd say more can be won by removing e.g. ASN.1 and X.509 for certificate handling and encoding that are a very difficult (impossible?) to get right and switch to something simple that solves the 99% use case of current TLS.
I agree with ASN.1 and X.509.
Those two are part of my plaintext-offenders list, like SMTP. They make life equally painful for both man and machine.