5 ms·

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

by favadi 11y ago

leftnode 11y ago
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.
StavrosK 11y ago
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.
- pfg 11y ago
  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-improved-handshakes-in-tls-13/ https://timtaubert.de/blog/2015/11/more-privacy-less-latency...
  - StavrosK 11y ago
    Very interesting post, thank you!
- drdaeman 11y ago
  > 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).
  - StavrosK 11y ago
    Sure, but it's a tradeoff between authentication and speed, in which many people may want to choose speed.
    - kardos 11y ago
      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.
      - StavrosK 11y ago
        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%.
        interurban 11y ago
        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.
        StavrosK 11y ago
        I made an events site for my city: http://www.tithess.gr/ 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"?
    - drdaeman 11y ago
      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.
- agildehaus 11y ago
  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.
- qrmn 11y ago
  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.
peterwwillis 11y ago
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
- drdaeman 11y ago
  > 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.
- mhurron 11y ago
  > Can only host one site per IP https://en.wikipedia.org/wiki/Server_Name_Indication 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.'
  - peterwwillis 11y ago
    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.
    - mhurron 11y ago
      I'm not saying that you were putting them forward as valid, I'm saying that list should be ignored.
r1ch 11y ago
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).
- Drdrdrq 11y ago
  I am quite sure ad networks will soon offer https variants of their code (if they don't already).
- manigandham 11y ago
  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.

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

by favadi 11y ago

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.

StavrosK 11y ago

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.

pfg 11y ago
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-improved-handshakes-in-tls-13/ https://timtaubert.de/blog/2015/11/more-privacy-less-latency...
- StavrosK 11y ago
  Very interesting post, thank you!
drdaeman 11y ago
> 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).
- StavrosK 11y ago
  Sure, but it's a tradeoff between authentication and speed, in which many people may want to choose speed.
  - kardos 11y ago
    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.
    - StavrosK 11y ago
      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%.
      - interurban 11y ago
        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.
        StavrosK 11y ago
        I made an events site for my city: http://www.tithess.gr/ 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"?
  - drdaeman 11y ago
    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.
agildehaus 11y ago
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.
qrmn 11y ago
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.

peterwwillis 11y ago

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

drdaeman 11y ago
> 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.
mhurron 11y ago
> Can only host one site per IP https://en.wikipedia.org/wiki/Server_Name_Indication 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.'
- peterwwillis 11y ago
  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.
  - mhurron 11y ago
    I'm not saying that you were putting them forward as valid, I'm saying that list should be ignored.

r1ch 11y ago

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).

Drdrdrq 11y ago
I am quite sure ad networks will soon offer https variants of their code (if they don't already).
manigandham 11y ago
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.