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

91–100 of 128 posts

Re: Https hurts users far away from the server

#91

Post by valarauca1 »

lclarkmichalek wrote: post #51
jacquesm wrote: post #44

The biggest impact you can have on your users experience is to trim down the number of connections and the size of your pages. Long after that you can start worrying about round-trip-times to the server. This blog post is a nice example: 30 requests (ublock origin blocked another 12, with those enabled the time to load increases to a whopping 28 seconds), 2.5M transferred, 7 seconds load time. And all that for 4K pay…

Number of connections isn't that relevant with HTTP2

Yes it is.

The number of connections to one host isn't relevant in HTTP2. As ublock is blocking some ~20 connections these are going to different hosts. Connecting to a different host in HTTP2 is no different then HTTP1.1

If your HTTP2 is terminating at MANY boxes within your infrastructure you are failing to understand how HTTP2 works. Connections within a single TLS/TCP/IP connection are free, new TLS/TCP/IP connections cost exactly as much as before.

Re: Https hurts users far away from the server

#92

Post by magicalist »

c0nfused wrote: post #49

It seems to me that it is worth considering that HTTPS is not always a panacea of goodness. We should think about two things. First that almost every firewall out there right now supports https snooping via MITM. Example: https://www.paloaltonetworks.com/features/decryption Second, I just got back from rural China where most unblocked american webpages take between 5-15 seconds to load on my mobile phone many of them…

> I forgot to pay me electric bill before I flew out and it took me nearly an hour to login, push pay my bill, accept the terms, and confirm payment. I was not a happy camper.

That sucks but I don't see how having a site where you may have to enter payment information on an unsecured connection would be a solution.

Re: Https hurts users far away from the server

#93

Post by lmm »

beardog wrote: post #58
hedora wrote: post #45

Presumably, cloudflare is up to its ears in NSL's, illegal wiretaps, etc. If you care at all about mass surveillance, censorship, oppressive governments (in the US, or the location of the cloudflare proxy) you probably should look elsewhere. It's probably controversial, but I'd love to see a yellow security icon in browsers when sites are using well known https relays that can see plaintext (or are doing other obviou…

I've seen this argument made a lot lately, and I agree Cloudflare is bad for user privacy, however, adding this warning to browsers by default wouldn't make a lot of sense. Heres why: Most websites are on virtual servers (hardware in general) that is not owned by them. For example, Amazon could easily let the NSA look into your AWS server directly. IMO, the url lock should just be an encryption auditor. The end websi…

I agree that CloudFlare with correctly configured HTTPS is no more vulnerable than AWS or really any popular host. All the lock icon confirms is that data is encrypted while it passes over the public Internet; what's happening inside the server at the other end is out of scope.

CloudFlare's "Flexible SSL" offering means a CloudFlare "https://" site is quite likely to not even have that level of security though. They send supposedly HTTPS data unencrypted and unauthenticated across the open Internet; if that doesn't warrant a yellow/red icon then I don't know what does.

Re: Https hurts users far away from the server

#94

Post by jacquesm »

tuxracer wrote: post #81
jacquesm wrote: post #72

Earlier quoted context omitted.

> And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2. Those are just ways to lose some of the impact of bloat without addressing the bloat itself. If you address bloat directly it will benefit all users.

If you migrate to HTTP2 or move to a host that already supports it then cutting down on "round trips" is an obsolete concern altogether.

HTTP2 does not magically bundle all connections to one. It still very much depends on how you build up your page.

Re: Https hurts users far away from the server

#95

Post by nandhp »

pfg wrote: post #82
hedora wrote: post #73

Earlier quoted context omitted.

Yes. This. In particular, the company operating the data center your server is in can reliably do this, and so can the backbone provider they use, and probably the server's local government. The DNS provider that controls your domain can mitm the ca process too (though with a higher chance of detection). The argument for making domain validation yellow (and not red) is that domain validation protects against attacks…

It's hard to say if you're implying this is any different with other validation levels like OV and EV. The validation methods that CAs may use for OV/EV are the same ones they may use for DV. The only difference is that they also validate the organization's information of the certificate requester. In other words, someone with the ability to MitM traffic between the CA and the target's domain could still obtain an OV…

> The only difference is that they also validate the organization's information of the certificate requester.

Right, but if I go to PayPal.com and the address bar says "Comcast [US]" or "National Security Agency [US]", I'll know something's up.

Re: Https hurts users far away from the server

#96

Post by Bartweiss »

throwawaysed wrote: post #89
hedora wrote: post #45

Presumably, cloudflare is up to its ears in NSL's, illegal wiretaps, etc. If you care at all about mass surveillance, censorship, oppressive governments (in the US, or the location of the cloudflare proxy) you probably should look elsewhere. It's probably controversial, but I'd love to see a yellow security icon in browsers when sites are using well known https relays that can see plaintext (or are doing other obviou…

Cloudflare is unquestionably a source of pure, unencrypted traffic for the govt. Does anyone remember a few years ago when Google found out through leaks that the govt was wiretapping it's private traffic between datacentres? What makes you so naive to think that the govt isn't sniffing every single page on cloudflare?

A 'counterpoint', such as it is. What makes you think that isn't happening to any 3rd party host you can name? Why single out Cloudflare as adding risk to sites that are hosted on AWS already?

The risk here is real, but it's much more pervasive than one data handler.

Re: Https hurts users far away from the server

#97

Post by hueving »

viggity wrote: post #76
jacquesm wrote: post #52

Earlier quoted context omitted.

Unfortunately back here in the real world only about 10% or so of all websites support HTTP/2 so it is very relevant.

yeah, but we're talking about what website operators can do to speed up their site. you can try to dramatically reduce the number of files you need to send. OR, you can just enable HTTP2. HTTP2 seems like a more simple answer.

HTTP2 doesn't magically change the number of hosts you communicate with (CDNs, ad networks, tracking providers, etc) and most importantly, it doesn't reduce the amount of shit developers are piling onto web pages.

Re: Https hurts users far away from the server

#98

Post by Symbiote »

chatmasta wrote: post #63
afandian wrote: post #29

Earlier quoted context omitted.

Vodafone in the UK did this to me.

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 simply blocked outright at either DNS or IP level, but I don't have a way to verify this, and can't find any details.

[1] https://wiki.openrightsgroup.org/wiki/Internet_censorship

[3] https://en.wikipedia.org/wiki/Child_abuse_image_content_list...

[2] https://wiki.openrightsgroup.org/wiki/Cleanfeed#cite_note-LI...

Re: Https hurts users far away from the server

#99

Post by jacquesm »

Bartweiss wrote: post #96
throwawaysed wrote: post #89

Earlier quoted context omitted.

Cloudflare is unquestionably a source of pure, unencrypted traffic for the govt. Does anyone remember a few years ago when Google found out through leaks that the govt was wiretapping it's private traffic between datacentres? What makes you so naive to think that the govt isn't sniffing every single page on cloudflare?

A 'counterpoint', such as it is. What makes you think that isn't happening to any 3rd party host you can name? Why single out Cloudflare as adding risk to sites that are hosted on AWS already? The risk here is real, but it's much more pervasive than one data handler.

You seem to mis-understand how cloudflare works. They allow an insecure host to pose as a secure one and the traffic between cloudflare and the insecure host is not encrypted.

That problem would not exist on 'any 3rd party host'.

Re: Https hurts users far away from the server

#100

Post by hayd »

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.

One way around this might be to use geolocation for dns http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rou...

Although doesn't help for all types of requests, it has its uses.

Post reply on HN