Hacker News Reader

Comment by daigoba66 | Hacker News Reader

That's great. Soon enough there won't be any excuse to not offer HTTPS.

Throughput drop and latency increase aren't solved by free certificates.

In throughput Netflix did a lot of work [1] to optimize HTTPS for their use case, and still went from 40 Gbps (network limited) to 10 Gbps (cpu limited). So they would need a 4x deployment to satisfy https everywhere to serve already encrypted files. This is probably not a big deal unless you're doing a pretty high volume of traffic, or have a really low powered server.

TLS setup adds at least one extra round trip to connection setup. This is a major latency penalty if you don't have servers close to your users. This is more likely to affect smaller sites/services, as geographic distribution comes at a signifigant cost (lots of servers + geodns/smart clients, or proxy through a cdn and lose end to end confidentiality)

[1] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

Given that they own the whole stack, there would be value in statically encrypting content and serving that through an unencrypted channel, after having served the correct parameters through an authenticated-encrypted channel of course.

Basically, something like serving a torrent file through HTTPS and then using standard, unencrypted, full-speed bittorrent for sending the raw data.

They don't control the browsers though.

They don't need to - if they serve the video player (Flash, JS, whatever) over HTTPS, they can then use it to verify the stream.

Since the files are public, static encryption wouldn't do any good - the attacker could still build a database of hashes of all encrypted files, and then identify what you downloaded. What they really need is to sign the files, to avoid tampering.

TLS actually supports this, using a NULL cipher - you can make a regular HTTPS connection where the domain is verified and the data is protected from tampering, but everything is in clear-text. Alas, browsers don't support this configuration, since it's usually used by mistake or as an attack.

So there are 2 things we want to protect against:

1. Attacker tampering with the data

2. Attacker learning what the user is watching

For 1. as I said the easy way is to distribute the torrent file through an authenticated, verified connection and then use that torrent file to get the raw data. Anything that doesn't hash to a piece in this torrent file is considered garbage.

For 2. that's an issue I didn't have in mind, and as long as the attacker can sign-in they can match an exchange with a database of hashes, so it's not protected in this regard.

I think there is already no excuse to not use HTTPs at this moment, no?

I think you're correct. The cost for an SSL certificate is trivial for any legitimate company, and the processing overhead to encrypt every request hasn't been a concern for years.

There sometimes may be an excuse in the extra roundtrips required to set up a TLS connection. For a public blog that doesn't accept submitting any information (like comments), for example, plain HTTP may be fine.

Fair enough. TLS 1.3 might introduce a zero-RTT handshake (with some security trade-offs), but that's obviously going to take quite some time to get rolled out.

Highly recommend this blog post [1] for more.

[1]: https://timtaubert.de/blog/2015/11/more-privacy-less-latency...

Very interesting post, thank you!

> For a public blog that doesn't accept submitting any information

TLS is not about accepting information, it's about ensuring that the connection's encrypted and authenticated.

It is still important to prevent unauthorized third parties from watching which articles you're reading. And it's still important that you know that you're reading a blog you expect to read, not a modified version served by someone else (although CA system isn't completely sufficient for this, at least it thwarts less-powerful adversaries from spoofing).

Sure, but it's a tradeoff between authentication and speed, in which many people may want to choose speed.

I'm having some difficulty thinking of a scenario where, given the choice, I'd trade off authentication for speed. The information would have to be of so little value that it doesn't matter if the remote party gets what I send or if I get what the remote party sends.

You're assuming that the probability of interception is 100% In reality, the probability of interception is miniscule, but the probability of speed is 100%.

The probability of interception is massively higher than miniscule, see the recent wide scale hijacking of Chinese traffic to DDOS Github or ISPs inserting ads and tracking into responses.

These types of attacks have been hypothetical for a long time, but we're starting to see real world impacts of not using https, and they aren't trivial.

I made an events site for my city:

http://www.tithess.gr/

The Greek government inserting ads into that site is very low on my list of concerns, but the additional 200-400ms on the first page load is much higher up.

Am I correct in understanding your point as "there can be no conceivable case where two fewer TCP roundtrips would be worth the speed gain over the decreased security"?

Weren't speed differences shown to be negligible?

Unless someone care about a single extra round-trip timing, e.g. extra 10-300ms with 300 being quite a stretch? I'm sure it doesn't matter if a blog page opens in 40ms or 55ms - a reader won't tell the difference.

I'm consistently seeing a 500ms difference between http://www.stavros.io and http://www.stavros.io with `time curl http://www.stavros.io`.

The blog for which you speak needs HTTPS too, as there's no way to guarantee the site hasn't been modified in-transit otherwise.

Injecting ads, changing content. All possible when the content isn't encrypted end-to-end.

I wish that were true, but honestly, plaintext isn't fine for anything at all in 2015, whether authenticated, important, public or otherwise, whether the network is the internet or a LAN.

HTTP sites have had attack scripts injected into them by nation-states, used to DDoS others on a massive scale - and that capability, and the desire to use it, is unfortunately proliferating rapidly.

Unless you want to be part of that problem, you're going to have to go HTTPS on everything - cat videos included - no matter how important or unimportant you think it is. I really wouldn't be surprised if tcp/80 goes the way of tcp/23.

On a brighter note - the speed difference is negligible with modern cryptography, and as others have mentioned, TLS 1.3 is developing handshakes with less TCP round trips. It's possible that a future protocol (taking into account what's been learned by Google's QUIC experiment) may deliver faster handshakes over UDP if possible to avoid the TCP handshake overhead - there's energetic research in that area at the moment.

Some excuses:

  - It's somewhat complicated for a site to implement correctly
  
  - It mainly protects users who have already connected to a site once 
    from a secure location and whose browsers support HSTS and other "fixes"
  
  - Circumvented easily via phishing
  
  - Does not prevent nation states from MITMing connection
  
  - Can only host one site per IP, without a wild-card or UCC cert 
    (which not all clients support)
  
  - Makes caching difficult to impossible
  
  - Adds performance overhead
  
  - Potential for new attacks on the TLS layer
    (SSL Strip, STARTTLS Command Injection, BEAST, POODLE, RC4, CRIME,
     TIME, BREACH, Truncation, FREAK, Logjam, Heartbleed, BERserk, 
     Root cert forgery, ChangeCipherSpec injection, Protocol downgrade, 
     Certificate errors, Renegotiation, Triple Handshake, 
     Virtual Host confusion, DoS)
  
  - General confusion by users as to what makes a connection secure

> Can only host one site per IP

Not really. SNI is about to be called "ancient". Well, it's not supported by IE on Windows XP, but good riddance.

> Can only host one site per IP

https://en.wikipedia.org/wiki/Server_Name_Indication

The rest of the excuses are basically 'it's not 100% perfect some of the time so why bother any of the time.'

Someone asked why somebody might not use HTTPS and i'm just saying what their excuses are. This isn't even a list of reasons why people cannot support HTTPS, which includes public agency policies, legacy support requirements, funding limitations and lack of resources.

I'm not saying that you were putting them forward as valid, I'm saying that list should be ignored.

Even without SNI, you can just add SAN names for all of your sites.

> - It's somewhat complicated for a site to implement correctly

This is true, but the same thing was said about running a site at all not long ago.

> - It mainly protects users who have already connected to a site once from a secure location and whose browsers support HSTS and other "fixes"

The point of using a valid CA is to allow the first connection be secure. It's certainly true that you can secure subsequent connections more than the initial one though.

> - Circumvented easily via phishing

Phishing is attacking something completely different and is not something SSL/TLS can or should protect you against. It's like expecting a seat belt to protect you from being run over.

> - Does not prevent nation states from MITMing connection

Actually it does if HPKP is used, though not on the initial connection.

> - Can only host one site per IP, without a wild-card or UCC cert (which not all clients support)

This is supported via the server name indication extension, and additionally by using multiple subject alternative names. The former is better though since it allows each site to have its own key.

> - Makes caching difficult to impossible

True, but that's a feature. Caching on the client is still of course entirely based on what the client chooses to do.

> - Adds performance overhead

Not much, see https://istlsfastyet.com/

> - Potential for new attacks on the TLS layer (SSL Strip, STARTTLS Command Injection, BEAST, POODLE, RC4, CRIME, TIME, BREACH, Truncation, FREAK, Logjam, Heartbleed, BERserk, Root cert forgery, ChangeCipherSpec injection, Protocol downgrade, Certificate errors, Renegotiation, Triple Handshake, Virtual Host confusion, DoS)

Note that there are protections again those, and saying "because it might have a problem" is basically just burying your head in the sand of the problem you already have.

> - General confusion by users as to what makes a connection secure

True, but not a good reason since you as a site owner can do most of the work for them (in combination with their browser).

- It's complicated to create a door lock

- It's somewhat complicated to install it on your door

- Government can kick your door down

- It takes time to turn the key to open the door

- Friendly neighbors can't just hop in whenever they like

- Confusion if door is locked or unlocked by looking at it

Hmm, let's keep our doors without locks then?

Ad supported sites can't really use it since the vast majority of ads are still not SSL compatible, meaning you get mixed content warnings (and no ads / revenue).

I am quite sure ad networks will soon offer https variants of their code (if they don't already).

Most ad networks aren't very technically savvy and some try to steal or capture more user data through normal http.

Any modern ad platform will support HTTPS and there are plenty of options. Many top publishers are already using HTTPS for the entire site so this isn't really a big issue.

Reply on news.ycombinator.com