Live data from Hacker News

Deprecating Non-Secure HTTP

blog.mozilla.org

301–310 of 318 posts

Re: Deprecating Non-Secure HTTP

#301
post #24

I should be happy about this -- who wouldn't want the entire web to be encrypted -- but SSL is so broken for normal people. SSL is expensive (wildcard certificates run $70 a year and up), confusing (how does one pick between the 200 different companies selling certificates?), and incredibly difficult to set up (what order should I cat the certificate pieces in again?). If SSL doesn't change, this move will cut the li…

Why this project: https://letsencrypt.org/ is so important. From the site: Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Arriving Mid-2015

The next problem is IP addresses. How is SNI these days? I've been meaning to experiment with it but the lack of extra personal certs have prevented me.

Re: Deprecating Non-Secure HTTP

#302

Earlier quoted context omitted.

No. Consider that DNS request/responses are simple, cleartext UDP packets. There's DNSSEC of course but nobody uses it (and also most security experts don't like it).

That's a bit silly, considering it was developed over a ten year process, and a lot of security professionals had a hand in its design. There are problems with it, which some people are quick to point out, and it is important to be aware of them. The fact that your DNS data is enumerable is an important change, for example. You could compare it to IPsec, which is what most VPNs use, which is comparable in security an…

> The fact that your DNS data is enumerable is an important change, for example.

Indeed, but afaik there are methods to mitigate it (NSEC3) and more refined ones in development (NSEC4, NSEC5).

Re: Deprecating Non-Secure HTTP

#303
post #183

This kind of implies that HTTPS is secure. :) I dont think there is anything wrong using HTTP internally in a datacenter for data that is not sensitive (like monitoring, statistics, etc.). I guess you can still access these in legacy mode. I think the title should be that HTTP is getting phased out for public internet use or something.

actually, its not really "safe behind a firewall" what if im inside the network i tell your monitoring that everythings ok while i break stuff?

and how is HTTPS protecting us against that? if you took over that IP address you can initiate a valid HTTPS session using the compromised server's identity and communicate with the monitoring service happily reporting fake data over HTTPS. I don't see your point. The question here is btw. is it worth X amount of dollar to protect this service with a secure channel? Sometimes the answer is yes, sometimes it is no.

Re: Deprecating Non-Secure HTTP

#304

Earlier quoted context omitted.

It's hardly rocket surgery though. Anyone incapable of following the steps required there is probably not who you'd want implementing your web server security…

Last time I tried, their site had JavaScript bugs and their email validation procedure didn't pass greylisting. I didn't want to place my web server security in the hands of a company with such low quality standards.

i had that problem when i used to run my own mail server (3 years ago). When did you last try?

Re: Deprecating Non-Secure HTTP

#305
Whole point of certs is to verify the site ownership. If getting certs is too easy, well those are then worthless. As it happens to be already. Email verification of domain ownership isn't good verification at all. These certs even if trusted are no different from self signed certs. IMHO.

Re: Deprecating Non-Secure HTTP

#306

Earlier quoted context omitted.

It's hardly rocket surgery though. Anyone incapable of following the steps required there is probably not who you'd want implementing your web server security…

That's the entire point. If the whole web is going to be secure, then someone who "is not who you'd want implementing your web server security" needs to be able to make it work, and work right.

Well, the counter argument is that even if the whole population is going to not have brain tumours - I _still_ don't want "someone who's not a rocket surgeon" doing brain surgery.

Crypto is non-trivial. There'll never be a proper "Click this button to automatically secure your random php app running in cPanel/Plesk".

The best we'll see I suspect is a "click here and make your website pass the minimal checks modern browsers use to determine if you're secure", then we'll have a daily stream of site owners claiming "the PII/password/creditcard breach wasn't my fault - I used 2048 bit encryption!"

Re: Deprecating Non-Secure HTTP

#307
post #258

Earlier quoted context omitted.

For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow). This doesn't make any sense. You're not waiting for DNS to propagate to clients; if anything you're waiting for recursive DNS servers at shitty ISPs to time out their caches when they are configured to not honor the RR's TTL sent by the authoritative server in a misguided attemp…

How often are DNS caches configured to ignore TTLs? That sounds awful. I assumed the grandparent simply didn't understand the need to lower his TTLs.

It is awful. It makes the standard way to plan and do a DNS migration really difficult.

It occurred rarely, but a few years ago it was a regular problem because some bigger ISPs were doing it[0]. Not sure how common it is these days.

That being said, I'm having troubling coming up with a project that would be better served with IP addresses than a constant name, so I have no idea what the OP I was responding to could be doing that that problem needed to be addressed at all.

[0] https://www.google.com/search?q=isp+ignore+dns+ttl

Re: Deprecating Non-Secure HTTP

#308
post #263
post #258

Earlier quoted context omitted.

How often are DNS caches configured to ignore TTLs? That sounds awful. I assumed the grandparent simply didn't understand the need to lower his TTLs.

Google DNS seems to ignore TTL but it does the opposite of what the GP is saying; gDNS drops it cache before the TTL is expired.

Unless you have a reference for Google saying they purposely do this, it is more likely that the cache is dropping LRU entries as it fills up. Also, I doubt there is a trivial number of actual resolvers behind the google public DNS endpoints, so you may be seeing the result of multiple individual servers without shared cache initially populating their caches.

Some quick tests with dig seem to indicate that, at least for the region I'm in, my queries to google's public DNS is rotating between 4 or 5 servers, as evidenced by the TTLs being returned.

Re: Deprecating Non-Secure HTTP

#309
post #145

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".

These devices don't have DNS They should, via mDNS AKA Zeroconf AKA Bonjour AKA Avahi. Often, printer-name.local port 80 or port 631 will lead to the printer's status page.

So vendors are supposed to pre-install a certificate based on that? What happens when you rename it? What happens if you have two of the same AP in the house?

Re: Deprecating Non-Secure HTTP

#310

Earlier quoted context omitted.

Who can intercept SSL traffic.

Only if they also control the PC or you allow them to install certificates. You can still safely use their network with your own device(s).

If they require proxy and root cert installation. They can do whatever they please.
Post reply on HN