Why SSL-everywhere is not necessarily a good idea in all circumstances | Hacker News Reader

Why SSL-everywhere is not necessarily a good idea in all circumstances

5 pointslisper10 comments

I'm in a remote location where the only comms are via a satellite link. This is what my internet connection looks like at the moment:

    [ron@mighty:~] ping google.com
    PING google.com (4.35.21.152): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    Request timeout for icmp_seq 4
    Request timeout for icmp_seq 5
    Request timeout for icmp_seq 6
    64 bytes from 67.201.56.75: icmp_seq=0 ttl=46 time=7264.039 ms
    64 bytes from 67.201.56.75: icmp_seq=1 ttl=46 time=6773.034 ms
    64 bytes from 67.201.56.75: icmp_seq=2 ttl=46 time=7007.539 ms
    64 bytes from 67.201.56.75: icmp_seq=3 ttl=46 time=6106.535 ms
    64 bytes from 67.201.56.75: icmp_seq=4 ttl=46 time=5740.475 ms
    64 bytes from 67.201.56.75: icmp_seq=5 ttl=46 time=5052.218 ms
    64 bytes from 67.201.56.75: icmp_seq=6 ttl=46 time=4352.883 ms
    64 bytes from 67.201.56.75: icmp_seq=7 ttl=46 time=3468.035 ms

Under these circumstances I can just barely open a regular HTTP connection, but most HTTPS connections time out before they can be established. So I can't do a Google search :-(

(Even submitting this to HN required multiple attempts.)

It's taking your connection 7 seconds to ping google.com.

No, we're not going to prevent and/or stone-wall encryption just so a connection with an average 7+ second latency works marginally better.

As an aside - this satellite connection is one of the worst ones I've seen. Old satellite connections are supposed to be on average about 1 second of latency[1] (and that's considered bad).

[1] http://arstechnica.com/information-technology/2013/02/satell...

The internet should be designed for 99% of users in 99% of cases. One edge case, while unfortunate, is not a very strong argument for why everyone sitting in Starbucks or McDonalds deserves to have their internet activity spied upon by anyone with a copy of Wireshark.

You may wish to get Opera browser and utilise their "Turbo" service (it is an optimising proxy, it compresses the page content, removing several round-trips, etc). Should have smooth out the issues a little bit.

> One edge case, while unfortunate, is not a very strong argument for why everyone sitting in Starbucks or McDonalds deserves to have their internet activity spied upon by anyone with a copy of Wireshark.

Who argued for that? Nobody has asked for SSL to be banned, or for SSL to not be available, or even that SSL shouldn't be the default.

So... What are they arguing for exactly? Nothing?

I think they're just trying to point out an instance where the overhead of SSL connections is a burden.

It's interesting. It's something that many developers wouldn't think about, but it has a real world consequence for this user in this instance.

Yes, we aren't going to throw away SSL because they had a bad experience, but it IS interesting to note, and it may even lead a few developers to think about how their tools could impact the users in non-optimal conditions.

It doesn't have to be an argument to be interesting...

Yes, exactly this. HN, for example, is ONLY available on HTTPS. That means that most of the time I can't access it. (Right now the situation is better -- only 750ms ping :-)

I learned a little while ago of the kinds of techniques games use to stay in near-realtime. One of these was "UDP spraying", repeatedly sending the same data packets (in a tight loop, using a significant amount of bandwidth) until they're acknowledged.

By your description it sounds like your current location is temporary (which is fortunate ;P) but that you'll revisit this location in the future, so it might be worth your while to explore different UDP data transfer algorithms once you're back with sane Internet, then test said techniques when you revisit where you are now.

Best case scenario, you might be able to tunnel TCP over some kind of "best effort" UDP retry algorithm that overcomes a proportion of the losses; it should be possible (while complicated) to implement a more intelligent packet-loss mitigation system that handles significantly broken connections better than TCP does.

A far simpler system might be a VT100-esque text terminal running on top of a best-effort transfer layer like those described above. The only problem with this method would be the input latency, although it may fare better than a browser overall (!).

Also, I'm not sure if it's relevant (my understanding of networking is sketchy), but I find it amusing that 67.201.56.75/0's description is "Zerolag Communications" xD (http://bgp.he.net/net/67.201.56.0/21)

There are plenty of situations in which SSL-everywhere is not useful, but it doesn't mean it isn't a good idea. You have a choice to encrypt your communications, and if you choose not to, you never know who is listening. A simple Google search isn't cause to need SSL usually, but say many various searches could give people insight into what your lifestyle is, and could narrow down various facts and information about you.

kinda off topic question but : Why is this under the "ask hn" label? It doesn't seem to be a question. Is it because the title starts with the word "why"? (Are submissions put under the sections based on titles automatically?)

I didn't put that label on. Maybe HN puts all text submissions under "Ask HN"?

Reply on news.ycombinator.com