
Why SSL-everywhere is not necessarily a good idea in all circumstances - lisper
I&#x27;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:<p><pre><code>    [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
</code></pre>
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&#x27;t do a Google search :-(<p>(Even submitting this to HN required multiple attempts.)
======
Alupis
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...](http://arstechnica.com/information-
technology/2013/02/satellite-internet-faster-than-advertised-but-latency-
still-awful/)

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

~~~
rlpb
> 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.

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

~~~
FooNull
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...

~~~
lisper
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 :-)

------
i336_
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](http://bgp.he.net/net/67.201.56.0/21))

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

------
drdeca
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?)

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

