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

An Update on the Lock Icon

blog.chromium.org

Post reply on HN
Print view View original

141–150 of 169 posts

Re: An Update on the Lock Icon

#141

Post by zamnos »

chrismorgan wrote: post #70
jefftk wrote: post #18

Earlier quoted context omitted.

> it supports SSL for some unfathomable reason. "neverssl.com now supports ssl, as some browsers and sites automatically use https even when you don't type that in. You get a browser-cacheable page that still helps you get online by forcing a request that ... never uses ssl." -- https://twitter.com/NeverSSL/status/1456310362551164928 They're trying to solve the "how do log into this captive portal" problem, and they…

Wow. Unfathomable indeed; that action and that explanation make no sense to me, and they haven’t even updated the HTML served—it still makes the claim of “never SSL” they’ve reneged on.

In the escalation of security, some browsers or browsers with extensions only ever try https, so that change was necessary to handle those browsers.

Re: An Update on the Lock Icon

#142

Post by s17n »

015a wrote: post #15

I think its possible there could be a backlash against this change, as even though many peoples' understanding of the security implications of the lock icon didn't align with reality, their expectation vis a vi "lock icon means secure, no lock means insecure, be careful if there isn't a lock" could force a broad unlearning of something that the security community has tried to teach over the past ten to fifteen years.…

Google’s blog was too polite to say it but the real point here is that whether a site has ssl support is now completely useless information. Any legit commercial site will have it, any malicious site will have it, the only sites that don’t are weird relics. So removing the lock icon makes sense regardless of how educated users are.

Re: An Update on the Lock Icon

#144

Post by zamnos »

chrismorgan wrote: post #70
jefftk wrote: post #18

Earlier quoted context omitted.

> it supports SSL for some unfathomable reason. "neverssl.com now supports ssl, as some browsers and sites automatically use https even when you don't type that in. You get a browser-cacheable page that still helps you get online by forcing a request that ... never uses ssl." -- https://twitter.com/NeverSSL/status/1456310362551164928 They're trying to solve the "how do log into this captive portal" problem, and they…

Wow. Unfathomable indeed; that action and that explanation make no sense to me, and they haven’t even updated the HTML served—it still makes the claim of “never SSL” they’ve reneged on.

Someone buy SometimesSSL.com and make it redirect to http://NeverSSL.com

Re: An Update on the Lock Icon

#145

Post by cyclotron3k »

I never understood why a website served using a self-signed (and untrusted) certificate would throw up more warnings than a website served without any encryption at all.

Even today, a page served over HTTP just gets an unobtrusive bit of text saying "Not secure", but if a page is served over HTTPS with a cert that expired yesterday you will get a very scary full-page warning that entirely blocks you from accessing the underlying page.

It seems totally backwards to me.

Re: An Update on the Lock Icon

#146

Post by aewens »

cyclotron3k wrote: post #145

I never understood why a website served using a self-signed (and untrusted) certificate would throw up more warnings than a website served without any encryption at all. Even today, a page served over HTTP just gets an unobtrusive bit of text saying "Not secure", but if a page is served over HTTPS with a cert that expired yesterday you will get a very scary full-page warning that entirely blocks you from accessing th…

An analogy may help, imagine the website as a door. A website using HTTP is a normal door and using HTTPS is a door with a lock, where the keyring in this analogy are the trusted CAs by your browser. A website using HTTPS with an expired certificate is a door that should have a lock, but the lock no longer latches; and a self-signed certificate is a locked door with a key left in the doorknob.

From a security perspective, a door without a lock has no expectation of protecting anything. But a door that should lock but doesn’t, or is supposed to be locked but has the key left in the latch is not providing the security expected, and should be given pause when anticipating security from the lock. This is what the browser is trying to translate with its UI.

Re: An Update on the Lock Icon

#147

Post by mgraczyk »

p1mrx wrote: post #16

If you're using Chrome, right-click the URL bar and check "Always show full URLs", so you can see the https:// prefix like it's 1999. This also fixes a variety of UX problems with editing URLs. By the way, does anyone know of a good alternative to http://neverssl.com ? I had been using this for years, but now it supports SSL for some unfathomable reason.

For some reason I remember reading that example.com will never have https, but I'm not sure that's true. It's what I use for now.

Re: An Update on the Lock Icon

#148

Post by aezart »

rootusrootus wrote: post #71

While we're fixing the UI for SSL, can we do something about unsecure connections to devices on my home network? At best I get a huge security warning that makes me jump through hoops to get past it, sometimes Chrome won't even let me get past without knowing the secret code. Surely we can figure out how to tell that a connection is only on the local network, and then give the user a one-time option to not worry abou…

I wound up just getting a signed cert for my home webserver. It wasn't too painful.

Re: An Update on the Lock Icon

#149

Post by chrismorgan »

zamnos wrote: post #141
chrismorgan wrote: post #70

Earlier quoted context omitted.

Wow. Unfathomable indeed; that action and that explanation make no sense to me, and they haven’t even updated the HTML served—it still makes the claim of “never SSL” they’ve reneged on.

In the escalation of security, some browsers or browsers with extensions only ever try https, so that change was necessary to handle those browsers.

I use HTTPS Only mode in Firefox. For a site like this, what I would expect is it to not accept connections on port 443, then my browser would issue a “Secure Site Not Available” error page, and I’d have to click the “Continue to HTTP Site” button to allow it to connect over HTTP for the rest of the session.

What happens is it just gets served over HTTPS—the one attempted HTTPS-on-apex-to-HTTP-on-subdomain redirect being translated to HTTPS-on-subdomain and the server shrugging and talking HTTPS on the subdomain without complaint—obviously undermining the whole point of the site.

To my knowledge, no browser configuration flat-out blocks cleartext HTTP; they’re all willing to compromise, and if you’re using neverssl.com you obviously intend to use that compromise. That’s why I say that both the action and the explanation make no sense to me; I cannot comprehend any way in which they actually help the site’s purpose, and the absurdity of it makes the site a laughing-stock.

Re: An Update on the Lock Icon

#150

Post by Someone »

mgraczyk wrote: post #147
p1mrx wrote: post #16

If you're using Chrome, right-click the URL bar and check "Always show full URLs", so you can see the https:// prefix like it's 1999. This also fixes a variety of UX problems with editing URLs. By the way, does anyone know of a good alternative to http://neverssl.com ? I had been using this for years, but now it supports SSL for some unfathomable reason.

For some reason I remember reading that example.com will never have https, but I'm not sure that's true. It's what I use for now.

It has https now. https://example.com/ works for me.
Post reply on HN