Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Https hurts users far away from the server

antoine.finkelstein.fr

Post reply on HN
Print view View original

31–40 of 128 posts

Re: Https hurts users far away from the server

#31

Post by ucho »

snug wrote: post #20
riobard wrote: post #9

Earlier quoted context omitted.

Here's why: Many ISPs hijack HTTP connections and inject ads and tracking JS into the page. If you don't use HTTPS, your page is screwed. The Internet is not a safe place. We should aim for HTTPS EVERYWHERE.

> Many ISPs I think that's a bit sensationalist.

Maybe it is even worse when it is just few - people won't know that website creator isn't responsible for all of its content. And sometimes is hard to know who is the culprit like in https://news.ycombinator.com/item?id=12091900 .

Is there any solution other than totally killing HTTP that protects from HTTPS stripping attacks? HSTS won't protect first visit and STS preload lists can only be so large.

Re: Https hurts users far away from the server

#32

Post by spand »

cmdrfred wrote: post #18
eganist wrote: post #7

Earlier quoted context omitted.

Keeping it extremely high level: Among other reasons, not encrypting traffic gives an opportunity for bad actors to replace content in transit to your end users when your end users are on compromised connections, such as rogue "free" wifi networks in airports or coffee shops, or even legitimate networks which have in some way been compromised, e.g. the ISPs of the world who decide to inject other content e.g. their o…

May I add an example. Let's say you are a drug company and you offer a number of different drugs. With TLS I only know that you are interested in a drug that company produces or the company itself, without it I know you or someone you care about has erectile dysfunction.

No that is not all an attacker could know. TLS does not provide confidentiality of the number of bytes transmitted. So in your example an attacker would only have to crawl the public website and find the pages matching in size to the ones you have been browsing.

Re: Https hurts users far away from the server

#33

Post by jlebrech »

alvil wrote: post #3

There is also another problem on how much and how often is Googlebot indexing your site because your site speed is one of the factors of so called Google index budget. My users are in Germany so my VPS is also in Germany to be fast for local user (~130ms for http reply), but for US Googlebot is my site slow (~420ms for http reply). So you are penalized also for this.

couldn't you make the indexable portion of your site fast and static and make it go to a relevant local server once users log in?

Re: Https hurts users far away from the server

#34

Post by amiraliakbari »

chatmasta wrote: post #5

What's wrong with the cloudflare free plan? You can host a static site on github pages with a custom domain and use the free cloudflare SSL cert.

The "Railgun" feature mentioned in the article is only available in some paid plans. Using the free plan wouldn't keep an open connection between your servers and Cloudflare's. It does improve the situation by terminating users' handshakes early, using better links, warm DNS cache, etc. among servers. But the latency hard limit is still present between your server and CF. Skipping https between your server and CL is not an option either for any site transferring user data.

Re: Https hurts users far away from the server

#35

Post by cmdrfred »

spand wrote: post #32
cmdrfred wrote: post #18

Earlier quoted context omitted.

May I add an example. Let's say you are a drug company and you offer a number of different drugs. With TLS I only know that you are interested in a drug that company produces or the company itself, without it I know you or someone you care about has erectile dysfunction.

No that is not all an attacker could know. TLS does not provide confidentiality of the number of bytes transmitted. So in your example an attacker would only have to crawl the public website and find the pages matching in size to the ones you have been browsing.

Good point I hadn't considered that.

Re: Https hurts users far away from the server

#36

Post by JimDabell »

riobard wrote: post #9
Kiro wrote: post #4

I don't understand why I need to use https on a static marketing webpage. No login stuff, no JavaScript, nothing. Just straight up HTML and CSS. Right now I need to pay about $150 every year for something that's only used to satisfy Google PageRank (I can't use LetsEncrypt with my hosting provider). Why?

Here's why: Many ISPs hijack HTTP connections and inject ads and tracking JS into the page. If you don't use HTTPS, your page is screwed. The Internet is not a safe place. We should aim for HTTPS EVERYWHERE.

Also transcoding images to be terrible quality. If you care about your images not looking like crap, you should serve them over HTTPS.

Re: Https hurts users far away from the server

#37

Post by Kiro »

RossM wrote: post #16
Kiro wrote: post #12

Earlier quoted context omitted.

Legacy and one of the only hosting providers in my country. I don't want to risk worse localized SEO by hosting it outside.

I've been reading up on localisation SEO lately - as far as I understand, Google only uses "server IP is located in X country" as an indicator of where a site might be localised for, if it can't get any better information. For example, if you're using a ccTLD for the domain, or if it's a generic-TLD and you declare a country in Google Webmaster Tools, that will be a much stronger weighting. Of course, if that's wrong…

Thank you. The actual web app is hosted on Linode in Frankfurt (using LetsEncrypt for https) so maybe I should host the marketing page there as well if that's true.

Re: Https hurts users far away from the server

#38

Post by mfontani »

Yup, and that's why for thereg we started using Cloudflare's Railgun… with it, the connection to the servers (hosted in the UK) is "bearable"… without, it's abysmal:

From a VPS in Sydney, with a Good Enough bandwidth:

    root@sydney:~# speedtest-cli 2>&1 | grep -e Download: -e Upload:
    Download: 721.20 Mbits/s
    Upload: 117.89 Mbits/s
… doing the request through Railgun is "quite bearable":

    root@sydney:~# ./rg-diag -json https://www.theregister.co.uk/ | grep -e elapsed_time -e cloudflare_time -e origin_response_time
    "elapsed_time": "0.539365s",
    "origin_response_time": "0.045138s",
    "cloudflare_time": "0.494227s",
Despite our "origin" server being quick enough, the main chunk of time is really "bytes having to travel half the world".

Why does railgun help? Because this is what a user would get otherwise; the "whitepapers" site is hosted in the UK, and doesn't use Cloudflare or Railgun – it only uses Cloudflare for DNS:

    ./rg-diag -json http://whitepapers.theregister.co.uk/ | grep elapsed_time
    "elapsed_time": "0.706277s",
… so that's ~200ms more, and _on http_.

How much would https add, if it were done without Cloudflare's https and Railgun? That's easy to check, as our the whitepapers site has TLS (although admittedly not http/2):

    root@sydney:~# ./rg-diag -json https://whitepapers.theregister.co.uk/ | grep elapsed_time
    "elapsed_time": "1.559860s",
that's quite a huge chunk of time that Cloudfalre HTTPS + Railgun just saves/shaves for us. Recommend it highly!

Re: Https hurts users far away from the server

#39

Post by paulddraper »

spand wrote: post #32
cmdrfred wrote: post #18

Earlier quoted context omitted.

May I add an example. Let's say you are a drug company and you offer a number of different drugs. With TLS I only know that you are interested in a drug that company produces or the company itself, without it I know you or someone you care about has erectile dysfunction.

No that is not all an attacker could know. TLS does not provide confidentiality of the number of bytes transmitted. So in your example an attacker would only have to crawl the public website and find the pages matching in size to the ones you have been browsing.

Cookies, user-agent header, and keep-alives will make that very hard to figure out.

Re: Https hurts users far away from the server

#40

Post by zhte415 »

alvil wrote: post #3

There is also another problem on how much and how often is Googlebot indexing your site because your site speed is one of the factors of so called Google index budget. My users are in Germany so my VPS is also in Germany to be fast for local user (~130ms for http reply), but for US Googlebot is my site slow (~420ms for http reply). So you are penalized also for this.

Your speeds seem very slow.

Is this the initial handshake which understandably introduces latency?

After that, times should be similar. What could be killing users far away is requiring multiple handshakes because multiple things requiring handshakes are being introduced at the same time.

For reference, I'm physically located in China so requests have to go through a bunch of filtering-oriented routers, and get 150-180ms from US, 200ms Japan and 180ms Singapore (yay geography) and around 200-250ms from Europe - this is SSL requests and not from a connections hub like Shanghai or Shenzhen close to domestic exit-points. Double to triple these times for first handshake.

Post reply on HN