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

Google Will Soon Shame All Websites That Are Unencrypted

motherboard.vice.com

Post reply on HN
Print view View original

101–110 of 369 posts

Re: Google Will Soon Shame All Websites That Are Unencrypted

#101

Post by Nullabillity »

geofft wrote: post #86
Nullabillity wrote: post #69

Earlier quoted context omitted.

I tried to set up LE for my personal bunch of websites, but sadly the rate-limiting is still too strict for automation to be a viable option.

Huh, the rate limits look pretty generous (500 certs every 3 hours): https://community.letsencrypt.org/t/rate-limits-for-lets-enc... Do you actually own hundreds of personal websites? (And you could still desync them, anyway.) Or is this a use case where wildcards would be useful. I sort of disagree with LE's decision to not care about wildcards for now, though I understand that it's simpler, at least while it's in b…

That's per IP, you're also limited to 5 requests per domain name per week. In my case, I have a bunch of subdomains for various stuff that all counts against the limit for the main website. I suppose I ought to combine the CSRs, but implementing that makes it a bit more complex than just automatically requesting a certificate per nginx vhost.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#102

Post by ryanlol »

nothrabannosir wrote: post #83
ryanlol wrote: post #65

Earlier quoted context omitted.

-o VisualHostKey=yes

A band-aid, I'm afraid. Without going into the question of how many bits of entropy that actually has when used with human beings in real settings, and just assume it's a perfect check; my question stands: how many people can you find who use this? Many SSH clients don't even support it, at all. PuTTY and almost anything that uses SSH for tunneling. When they do: how many of your hosts do you know the image of? Again…

>Without going into the question of how many bits of entropy that actually has when used with human beings in real settings, and just assume it's a perfect check; my question stands: how many people can you find who use this?

Probably not very many, but it's really only useful for people that ignore basic security features anyway. (Key auth)

>When they do: how many of your hosts do you know the image of?

None, I use key auth like any reasonable person would.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#103

Post by wbillingsley »

kuschku wrote: post #92
wbillingsley wrote: post #87

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.

I thought about that, but there's so many DNS caches out there with potential bugs to make them insecure and poisonable.

But a set of public keys from the registrar is "content". It's small, so they could just have a server or two to handle it. (But if load/latency was an issue, well everyone's pretty good at content-distribution networks these days...)

Re: Google Will Soon Shame All Websites That Are Unencrypted

#104

Post by x0 »

oliv__ wrote: post #23

Why do we have to go through this whole SSL certificates thing and can't just have a simple, automatically secure, I-do-nothing-and-my-website-is-secure protocol? Seriously though. If secure is the default from now on, why can't it actually be the default?

Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#105

Post by ryanlol »

forgottenpass wrote: post #59
rwmj wrote: post #31

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?

But the worst case scenario with SSH MitM isn't someone being able to eavesdrop on your connection. But someone pretending to be the server, which is hardly as serious. (Unless you're using password auth, in which case you deserve to get owned)

Re: Google Will Soon Shame All Websites That Are Unencrypted

#106

Post by toyg »

CydeWeys wrote: post #97
eyuelt wrote: post #91

Earlier quoted context omitted.

Sure they can. Your ISP can easily MitM you.

Not without throwing cert errors on every site I visit. The only way they can MITM me is if they compromise my PC as well and install their root CA.

... or rather get an intermediate certificate from one of the umpteen root CAs your operating system embeds by default.

Is VeriSign going to refuse a certificate to AT&T?

Re: Google Will Soon Shame All Websites That Are Unencrypted

#107

Post by notatoad »

ergothus wrote: post #66
gesman wrote: post #26

Google should offer stupid SSL certificates either for free or for $1/yr. Perhaps at least to customers of Google domains. I won't mind switching from namecheap to Google domain in latter case.

Getting a Google domain means giving up getting new features from Google :( (pauses to clean up bitterness)

No, it does not. Signing up for google apps and choosing to use the google apps account as your primary google user account causes you to get new features on a delayed schedule.

You can get a domain through google without switching your google identity to it. You can also sign up for google apps on a non-google domain. google domains and google apps are not the same thing.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#108

Post by EGreg »

mholt wrote: post #96

In the hopes that it will help spread adoption of HTTPS, I wrote a web server that serves your sites over HTTPS by default, using Let's Encrypt: https://caddyserver.com - It also redirects HTTP -> HTTPS.[1] 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…

Here's a good excuse for not using https for everything: it breaks caching of files by proxies!

Re: Google Will Soon Shame All Websites That Are Unencrypted

#109

Post by snowwrestler »

toyg wrote: post #106
CydeWeys wrote: post #97

Earlier quoted context omitted.

Not without throwing cert errors on every site I visit. The only way they can MITM me is if they compromise my PC as well and install their root CA.

... or rather get an intermediate certificate from one of the umpteen root CAs your operating system embeds by default. Is VeriSign going to refuse a certificate to AT&T?

Verisign will happily issue a certificate to AT&T for a domain that AT&T controls.

Verisign will not issue a certificate to AT&T for google.com--no matter how nicely AT&T asks.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#110

Post by geofft »

drdaeman wrote: post #93
geofft wrote: post #47

Earlier quoted context omitted.

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 thought the same, but reality isn't that nice. Got this response: https://news.ycombinator.com/item?id=10602621 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 enco…

I don't currently see a 500 ms difference, so maybe they figured something out. From my shell, I see about 35 ms to http://www.stavros.io/404 and about 85 ms to https://www.stavros.io/404 (the HTTPS site serves actual content and the HTTP a redirect, which confounds the numbers).

The HTTPS server is currently offering me a 4096-bit-RSA certificate, signed by the 2048-bit-RSA StartCom class 1 intermediate CA. There's no security benefit in a 4096-bit cert signed by a 2048-bit one, since any attacker capable of breaking 2048-bit RSA but not 4096-bit is just going to attack the CA cert and sign their own forged cert (and any attacker sorta capable of breaking 2048-bit RSA will dedicate their brute force effort to CA certs). And to my knowledge, all current CA intermediate certs are 2048-bit. Meanwhile, because of math, 4096-bit certs take a lot longer to handshake: see e.g. https://certsimple.com/blog/measuring-ssl-rsa-keys

CertSimple's data indicates a 25 ms difference between 2048-bit and 4096-bit keys on their server, so I'd expect that the 4096-bit key is responsible for at least most of the performance difference here. A few years ago I screwed this up on a production shared web host, and I believe we saw a greater than 50 ms difference. (While we're at it, that cert is SHA-1, so it's possible they can get a reissue for free.)

Were you able to replicate the 500 ms (!) performance difference on your own server? Are you using a 2048-bit cert and reasonable cipher suites?

Post reply on HN