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

Deprecating Non-Secure HTTP

blog.mozilla.org

Post reply on HN
Print view View original

141–150 of 318 posts

Re: Deprecating Non-Secure HTTP

#141

Post by schoen »

pfg wrote: post #137
schoen wrote: post #120

Earlier quoted context omitted.

Right now the subject identifier in a Let's Encrypt cert must be a DNS name, not an IP address. From the ACME protocol specification draft: "Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case addressed by this document is the case where domain names are used as identifiers. For example, all of the identifier validation challenges describ…

This is in line with other CAs - no certificates should be issued for IP addresses or internal server names with expiry dates after November 2015. See for example: https://www.digicert.com/internal-names.htm

Technically I think the requirement Digicert is referring to only forbids issuance for "reserved" IP addresses.

https://cabforum.org/internal-names/

The PDF document defines "Reserved IP Address" as "An IPv4 or IPv6 address that the IANA has marked as reserved".

Re: Deprecating Non-Secure HTTP

#142

Post by icebraining »

XorNot wrote: post #107

If you really want to tackle SSL make it less stupid. Self-signed certificates? I want these pinned and treated as secure. I want a notification if they change around the time they expire and a really big warning if they don't. If we must have central trust sources, then have central hash servers so when I visit a new self-signer I can externally verify the hash.

Say the owner of a website with a self-signed cert fears it might have been compromised, and decides to create a new cert. How is the user supposed to distinguish that from a MITM?

Re: Deprecating Non-Secure HTTP

#143

Post by icebraining »

J_Darnley wrote: post #110

Great! Now I just need to setup ssl on my Raspberry Pi to access the several web interfaces I have running there. Oh wait. I'm no longer running Firefox, I won't have to worry about this immediately.

If you're running Chrome instead, you still do; they have similar plans.

Re: Deprecating Non-Secure HTTP

#144

Post by icebraining »

angersock wrote: post #28
sergiotapia wrote: post #14

Why do we have to pay for an SSL certificate? Shouldn't it be free?

You would think so. The problem is that browsers have gone and made self-signed certs suspect, and yet not created, for example, a well-established foundation for signing such certs.

It's exactly what they're doing with Let's Encrypt.

Re: Deprecating Non-Secure HTTP

#145

Post by zaroth »

Mentioned this last time, but since I didn't see it elsewhere in the thread, will mention it again... what about LAN resources served over HTTP like NAS, Printer, AP, etc.? These devices don't have DNS, forget about about SSL.

Is the entire local subnet going to be a secure origin like localhost? Because that sounds problematic... What I want is a way to single-click pin a self-signed certificate to "turn it green".

Re: Deprecating Non-Secure HTTP

#147

Post by oldmanjay »

Touche wrote: post #128
kijin wrote: post #111

Earlier quoted context omitted.

This is a legitimate concern, but I think the so-called dire consequences are a bit overblown. Major browser vendors like Google and Mozilla don't change their policies in a vacuum while the rest of the world stays static. The move to "deprecate" HTTP is an explicit attempt to manipulate the rest of the world into making SSL easier and more affordable. It is unfair to evaluate this proposal in isolation without consi…

> The move to "deprecate" HTTP is an explicit attempt to manipulate the rest of the world into making SSL easier and more affordable. It is unfair to evaluate this proposal in isolation without considering the market upheaval that it is very much intended to trigger. I'd love to believe this but I've never once seen the https-only nazis bring up this issue on their own, or show any concern for the fact that it will l…

I'm not convinced that's the backbone of the web at all. Can you back up your assertion with anything beyond emotional pleading?

Re: Deprecating Non-Secure HTTP

#148

Post by teraflop »

sfilipov wrote: post #140
teraflop wrote: post #87

Earlier quoted context omitted.

Not a bad idea, in theory, but... suppose I visit a site on Monday and see certificate A. Then when I return on Tuesday, I see a different certificate B. What reason is there to think that A is likely to be the "true" certificate, and B isn't? Showing a big scary warning in one case, and not in the user, implies to the user that the browser has some reason to think one is more secure, which is misleading.

You could use some website which you connect to securely (CA signed) which fetches and displays fingerprint C. You can then compare it to A and B and the one which matches C is the "true" one. Of course the whole thing can be automated by the browser and happen behind the scene - i.e. Firefox connecting to a Mozilla service for each self signed website it sees and comparing the fingerprints. Then it can store informa…

That sounds essentially the same as how Let's Encrypt works: https://letsencrypt.org/howitworks/technology/

Except that rather than creating a self-signed certificate and then asking an external service to store a fingerprint, you just let the external service sign your certificate.

EDIT: Oh yeah, and signing the certificate up-front has the nice benefit of not forcing browsers to leak private information (namely, the domain names that are being accessed) to a centralized third party.

Re: Deprecating Non-Secure HTTP

#149

Post by wampus »

Touche wrote: post #128
kijin wrote: post #111

Earlier quoted context omitted.

This is a legitimate concern, but I think the so-called dire consequences are a bit overblown. Major browser vendors like Google and Mozilla don't change their policies in a vacuum while the rest of the world stays static. The move to "deprecate" HTTP is an explicit attempt to manipulate the rest of the world into making SSL easier and more affordable. It is unfair to evaluate this proposal in isolation without consi…

> The move to "deprecate" HTTP is an explicit attempt to manipulate the rest of the world into making SSL easier and more affordable. It is unfair to evaluate this proposal in isolation without considering the market upheaval that it is very much intended to trigger. I'd love to believe this but I've never once seen the https-only nazis bring up this issue on their own, or show any concern for the fact that it will l…

The move to deprecate HTTP is solely inspired by the need to authenticate online communication. It's necessary to protect speech on the web, because it makes it harder to tamper with the content in transit. Your ISP shouldn't be able to inject ads into a web page, a WiFi access point shouldn't be able to change every "do" to "do not", and a passive listener shouldn't be able to collect information about you for his own gain. SSL/TLS is a huge mess and the current CA situation is abysmal, but authentication needs to happen now, or there will be no privacy or freedom on the Internet.

Re: Deprecating Non-Secure HTTP

#150

Post by pfg »

schoen wrote: post #141
pfg wrote: post #137

Earlier quoted context omitted.

This is in line with other CAs - no certificates should be issued for IP addresses or internal server names with expiry dates after November 2015. See for example: https://www.digicert.com/internal-names.htm

Technically I think the requirement Digicert is referring to only forbids issuance for "reserved" IP addresses. https://cabforum.org/internal-names/ The PDF document defines "Reserved IP Address" as "An IPv4 or IPv6 address that the IANA has marked as reserved".

Missed that, thanks!
Post reply on HN