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…
Https hurts users far away from the server
51–60 of 128 posts
Re: Https hurts users far away from the server
#52The 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
Re: Https hurts users far away from the server
#53I 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?
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…
don't know the answer myself here.. there are good technical reasons, I agree..
but it is a logical fact that if google search was always 100%, there would be no need for adwords and site ads...
Re: Https hurts users far away from the server
#54Presumably, 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…
A mini audit along the lines of 'builtwith'. Hm. Good idea, why not go a step further and turn the 'no server signatures' advice on it's head: full disclosure, server signatures on, in fact, list each and every component in the stack so that end users can (through some plug-in) determine whether or not a site is safe to use. Of course nothing bad could ever come from that. /s I'm all for making the use of for instanc…
FWIW, my personal website uses let's encrypt, so it would be yellow or worse.
Anyway, I like the idea of tying the security color in the url bar to an attacker model, since it at least gets people to think about attack models.
Re: Https hurts users far away from the server
#55I 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?
Most of the answers you're getting aren't all that big of deal for your site. You still might want https though. You should think about https for sites like yours the way you think about vaccines. SSL everywhere makes everyone safer, even though it doesn't have a tremendous impact on your own site. Also, shameless plug, if you want really easy SSL you can use our new startup: https://fly.io . I'm not sure what countr…
Re: Https hurts users far away from the server
#56Re: Https hurts users far away from the server
#57What'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…
I understand that by using the generic CF free cert, https terminates at CF and the connection CF->Origin is over unencrypted HTTP. Is this why there is latency overhead? Because CF cannot connect to origin via https so it cannot open a persistent tunnel? Or is it because the overhead of keeping an open https tunnel per origin server is prohibitively expensive to maintain for every free customer?
I assume that even though there is no persistent tunnel, CF still must still use persistent TCP connections?
Re: Https hurts users far away from the server
#58Presumably, 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…
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 website is using acceptable algorithms and has a currently valid certificate? That's good enough.
Almost any HTTPS site can be forged/"broken" (unless they're using preloaded HPKP), if the attacker has root certificates (or even just a bug in a CA website), which the NSA certainty does.
Nation state adversaries just aren't really within the typical TLS threat model. I do concede that it does make agencies jobs much harder if used correctly, however.
Re: Https hurts users far away from the server
#59Earlier quoted context omitted.
A mini audit along the lines of 'builtwith'. Hm. Good idea, why not go a step further and turn the 'no server signatures' advice on it's head: full disclosure, server signatures on, in fact, list each and every component in the stack so that end users can (through some plug-in) determine whether or not a site is safe to use. Of course nothing bad could ever come from that. /s I'm all for making the use of for instanc…
It would have to work without the site's permission, so the browser (or maybe a third party service) would do a basic vulnerability scan. Maybe orange could mean "a script kiddie could pwn this site in under an hour", and yellow would mean "we don't see how your ISP could mitm this, but server side providers (aws, google, azure cloudflare) definitely could." FWIW, my personal website uses let's encrypt, so it would b…
Re: Https hurts users far away from the server
#60Earlier quoted context omitted.
Number of connections isn't that relevant with HTTP2
Unfortunately back here in the real world only about 10% or so of all websites support HTTP/2 so it is very relevant.