91–100 of 369 posts
Earlier quoted context omitted.
How does it get rid of competing ad networks? Does Google have a monopoly on serving ads over HTTPS?
It means your internet provider can't inject ads or profile you based on the content of the sites that you visit. Comcast, AT&T, and Verizon have all done similar: https://certsimple.com/blog/ssl-why-do-i-need-it#4-not-havin...
Surely it could be a lot easier... Everyone already has a known public third party authority -- their domain registrar. Surely the browsers could come up with some protocol where you generate your own keypair, register the public key with the registrar and keep the private key on the server. Then it could work pretty much like SSH, but with the browser doing out-of-band public key checking. Rather than needing a cert…
Put the public key in DNS, auth the DNS.
So what about the overhead of https?
For the last few years, effectively zero. https://istlsfastyet.com/ https://www.maxcdn.com/blog/ssl-performance-myth/ https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h... Not to mention that if you use CloudFlare just to get a free SSL certificate out of them, you're also getting a CDN, so the performance overhead is negative .
I was able to replicate this on my own server too, but haven't immediate solution (all the obvious things like OCSP stapling were already configured, following common sense and various "best practices" guides) and I hadn't enough spare time to properly investigate why TLS takes longer.
If someone had encountered this or knows the possible culprits, would be glad to hear suggestions.
Earlier quoted context omitted.
HTTPS does not kill referrer or referer headers. See https://referer.rustybrick.com/
..so why are all of the search terms suddenly gone from google searche referer headers? Which happened at the same time google defaulted to https?
When the SERP loads, all the results link to the real webpages, so that you see their address in the browser status bar when hovering over a link. Clicking any result link triggers a script that replaces the URL with https://google.com/url?url=the_real_webpage_url.
When you click through, you're clicking a link from google.com to another link on google.com, which redirects to the webpage you intended to visit. The referrer the webpage sees is the intermediate google.com/url page, instead of the search result page. This prevents websites from getting search term data from the SERP URL, if it was present, by removing that URL from referrer headers entirely.
There's a lot of misinformation out there about certificates and HTTPS, but don't let it stop you from encrypting your site. Regardless of Google's move, there is no excuse for any site not to be served encrypted anymore.
[1] Here's a 30s demo: https://www.youtube.com/watch?v=nk4EWHvvZtI
Earlier quoted context omitted.
It means your internet provider can't inject ads or profile you based on the content of the sites that you visit. Comcast, AT&T, and Verizon have all done similar: https://certsimple.com/blog/ssl-why-do-i-need-it#4-not-havin...
Sure they can. Your ISP can easily MitM you.
The only way they can MITM me is if they compromise my PC as well and install their root CA.
Surely it could be a lot easier... Everyone already has a known public third party authority -- their domain registrar. Surely the browsers could come up with some protocol where you generate your own keypair, register the public key with the registrar and keep the private key on the server. Then it could work pretty much like SSH, but with the browser doing out-of-band public key checking. Rather than needing a cert…
Even better. Put the public key in DNS, auth the DNS.
It gets some pushback from notable security experts (e.g. tptacek here) because the DNS system (notably the root) is largely state-owned, while registrars are largely privatized.
Earlier quoted context omitted.
SSH gets this right -- create a host key when the server is installed, and have the client check the key and only warn/error when it changes. Sure, this isn't super-secure for first time visitors to their banking website or whatever, but those websites can continue to use the current system.
SSH gets this right No, it doesn't. When was the last time you verified a host key out of band? And if you're using SSH, you know well enough to know why you should do the damn legwork to verify the key. What do you expect for end users? Furthermore, if nobody is doing out of band verification on the first pass, how do you expect users to distinguish between an attack and legit host key change?
Which is hilarious because the reason I can't switch The New Yorker website to HTTPS is because of ads - which I'm getting from Google DFP which allows non-secure ad assets. In short; Google will penalize me because I use Google. The universe has a sense of humor.