Https hurts users far away from the server • Hacker News Board

Re: Https hurts users far away from the server

#111

Post by citrin_ru » Fri, Mar 10, 2017, 7:58 PM UTC

hannob wrote: post #28

There are a couple of other things you can do with existing TLS technology that can improve your latency, e.g. using OCSP stapling, use modern crypto so browsers may use TLS false start, avoid too many ciphers or unnecessary certs in the chain to make the handshake smaller. It's a bit older, but here's some info, much of it is still valid: https://istlsfastyet.com/

It is questionable if OCSP stapling reduces TLS handshake time.

Without OCSP browser makes slow request to CA, but caches results for a long time so slow request happens not often.

With OCSP stapling enabled more data is transferred between client and server on each TLS handshake.

Main proponents of OCSP stapling are CA, because it saves them bandwidth/hardware.

Re: Https hurts users far away from the server

#112

Post by problems » Fri, Mar 10, 2017, 8:27 PM UTC

manigandham wrote: post #105

problems wrote: post #10

Earlier quoted context omitted.

Yeah, at a $200/mo cost, you could spin up a few VMs on DigitalOcean, Vultr or LightSail which have decent bandwidth and cache from there. Nice part about cloudflare though is that they can use anycast to determine location and then send the closest server IPs. For sub-$200/mo, you're not able to do that, you'd have to find a provider that could do it for you, I'm not sure anyone offers country-based anycast DNS alon…

> anycast to determine location and then send the closest server IPs Anycast doesn't determine location or send the closet IPs, it's all the same IP address announced using BGP (border gateway protocol) to automatically route to the closest (in network travel) server.

Of course. Let me clarify - they use anycast DNS to send the closest CF caching proxy's IP.

Re: Https hurts users far away from the server

#113

Post by kuschku » Fri, Mar 10, 2017, 8:39 PM UTC

KabuseCha wrote: post #84

alvil wrote: post #64

Earlier quoted context omitted.

Report tool I use is Google's official webmaster tool (420ms an average time in "crawl stats"). And here is the article on budget https://webmasters.googleblog.com/2017/01/what-crawl-budget-...

Hi, alvil - 420ms does not sound that bad. Checking some of my sites I see: - values ranging vom 320 - 410 for a bunch of German speaking sites hosted in Europe - and values of 221 and 240 for my two English speaking sites hosted in America (via firebase - on googles own infrastructure) So if you are concerned with your crawl budget, I think you better focus on things like: - On-site duplicate content - Soft error pa…

> Choose a server near you and aim for a Speed-Index of maximum 3000 - I personally target 1000, but depending on your influence regarding the website's frontend you will not be able to achieve this.

For some comparison results: Uncached, with my own CMS indexing and analyzing a 6GB database of crashdumps and providing an overview with graphs over that, I get a score of 623. (This running on a 9€/mo dedicated server).

Re: Https hurts users far away from the server

#114

Post by pfg » Fri, Mar 10, 2017, 8:44 PM UTC

citrin_ru wrote: post #111

hannob wrote: post #28

There are a couple of other things you can do with existing TLS technology that can improve your latency, e.g. using OCSP stapling, use modern crypto so browsers may use TLS false start, avoid too many ciphers or unnecessary certs in the chain to make the handshake smaller. It's a bit older, but here's some info, much of it is still valid: https://istlsfastyet.com/

It is questionable if OCSP stapling reduces TLS handshake time. Without OCSP browser makes slow request to CA, but caches results for a long time so slow request happens not often. With OCSP stapling enabled more data is transferred between client and server on each TLS handshake. Main proponents of OCSP stapling are CA, because it saves them bandwidth/hardware.

Thinking about this a bit, it seems to be that clients talking to a server with OCSP stapling support could still make use of cached OCSP responses by simply omitting the "status_request" extension in the client hello, which would cause the server not to send the stapled OCSP response. I don't think any clients behave that way today, though.

I'm not certain how session resumption plays into this either. If OCSP is skipped for resumed session as well (which would be my guess), you'd probably not take that small bandwidth hit all that often.

As an aside, OCSP stapling improves your user's privacy quite a bit as well, by not giving your CA a list of all IP addresses connecting to a domain.

Re: Https hurts users far away from the server

#115

Post by manigandham » Fri, Mar 10, 2017, 8:50 PM UTC

problems wrote: post #112

manigandham wrote: post #105

Earlier quoted context omitted.

> anycast to determine location and then send the closest server IPs Anycast doesn't determine location or send the closet IPs, it's all the same IP address announced using BGP (border gateway protocol) to automatically route to the closest (in network travel) server.

Of course. Let me clarify - they use anycast DNS to send the closest CF caching proxy's IP.

That's not how it works. Both their DNS and reverse proxy servers use anycast IPs without any DNS-based routing.

They did recently release some features called traffic manager that lets you control the origin server based on geo. If you just need geo-balanced DNS though, AWS Route 53, Azure Traffic Manager, and NSOne offer DNS based routing.

Re: Https hurts users far away from the server

#116

Post by problems » Fri, Mar 10, 2017, 8:54 PM UTC

manigandham wrote: post #115

problems wrote: post #112

Earlier quoted context omitted.

Of course. Let me clarify - they use anycast DNS to send the closest CF caching proxy's IP.

That's not how it works. Both their DNS and reverse proxy servers use anycast IPs without any DNS-based routing. They did recently release some features called traffic manager that lets you control the origin server based on geo. If you just need geo-balanced DNS though, AWS Route 53, Azure Traffic Manager, and NSOne offer DNS based routing.

Really? I didn't think they'd do anycast on their reverse proxy servers, that seems risky to me (ie: a TCP connection changes from one server to another due to a BGP change), but I suppose the odds are fairly low.

I seem to remember getting different IPs from different locations, but it could just be random or I could be mistaken.

EDIT: Tried now and it seems I'm getting the same IPs from Canada and Australia, so you are indeed correct.

Re: Https hurts users far away from the server

#117

Post by manigandham » Fri, Mar 10, 2017, 9:00 PM UTC

problems wrote: post #116

manigandham wrote: post #115

Earlier quoted context omitted.

That's not how it works. Both their DNS and reverse proxy servers use anycast IPs without any DNS-based routing. They did recently release some features called traffic manager that lets you control the origin server based on geo. If you just need geo-balanced DNS though, AWS Route 53, Azure Traffic Manager, and NSOne offer DNS based routing.

Really? I didn't think they'd do anycast on their reverse proxy servers, that seems risky to me (ie: a TCP connection changes from one server to another due to a BGP change), but I suppose the odds are fairly low. I seem to remember getting different IPs from different locations, but it could just be random or I could be mistaken. EDIT: Tried now and it seems I'm getting the same IPs from Canada and Australia, so you…

Yes, they have a big address space and announce all ips from every location: https://blog.cloudflare.com/cloudflares-architecture-elimina...

Pretty much all major CDNs use anycast today for load balancing, rolling downtime and security/ddos protection. Http/tcp connections are usually short-lived, relatively cheap to setup (since it's an edge network anyway) and BGP route updates don't happen that often.

LinkedIn switched to anycast too after testing: https://engineering.linkedin.com/network-performance/tcp-ove...

Re: Https hurts users far away from the server

#118

Post by kuschku » Fri, Mar 10, 2017, 9:58 PM UTC

aanm1988 wrote: post #110

> In our case at Hunter, users were waiting on average 270ms for the handshake to be finished. Considering requests are handled in about 60ms on average, this was clearly too much. Why? Did it hurt user engagement? Were people complaining the site was slow?

The question is "is this the best we can do?".

If it’s no, then clearly we should improve.

Re: Https hurts users far away from the server

#119

Post by StavrosK » Fri, Mar 10, 2017, 10:14 PM UTC

220 wrote: post #108

StavrosK wrote: post #79

Earlier quoted context omitted.

The attack is definitely transparent if you trust the CA that issued the MITM cert.

If you use cert pinning, like the DigiNotar/Iran/Gmail, you're still protected against a trusted CA, assuming you've communicated in the past, which is realistic for a real world attack. It's an attack that's difficult to deploy because it's easy to detect if you're looking in the right places, and as soon as it's detected, you know the CA has been compromised, and the attacker loses a large investment.

It's not as difficult to deploy if you can only target specific users, but I agree with you. The problem with cert pinning is that it's hard to do, because, if you make a mistake, nobody can access your site for quite a long time...

Re: Https hurts users far away from the server

#120

Post by chatmasta » Fri, Mar 10, 2017, 11:53 PM UTC

Symbiote wrote: post #98

chatmasta wrote: post #63

Earlier quoted context omitted.

Vodafone is the worst. Although it's really the U.K. surveillance state that is the problem. When I popped my SIM into my iPhone it forced me to download a configuration profile with a self-signed Vodafone cert, which means they can mitm any connection. I think this is required by the government so they can block adult websites by default? (I've also seen torrent websites also fail silently with misleading "server no…

I have never heard of the self-signed certificate, that would be interesting to report to the Open Rights Group [1] The filtering in the UK is by inspecting HTTP requests, so when a single image on wikipedia.org was blocked, every request to Wikipedia ended up going through each ISPs hidden proxy. [3] According to [2], HTTPS sites aren't filtered -- but it references a page from 2004. I suspect HTTPS sites are now si…

Here are some screenshots of the text I got and the profile I had to install.

Correct me if I'm wrong but I'm pretty sure this enables complete MITM by Vodafone when using cellular network.

http://imgur.com/b0il5xb http://imgur.com/3mw5ZGZ http://imgur.com/6ehhfuZ