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
Deprecating Non-Secure HTTP
301–310 of 318 posts
Re: Deprecating Non-Secure HTTP
#302Earlier 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…
Indeed, but afaik there are methods to mitigate it (NSEC3) and more refined ones in development (NSEC4, NSEC5).
Re: Deprecating Non-Secure HTTP
#303This 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?
Re: Deprecating Non-Secure HTTP
#304Earlier 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.
Re: Deprecating Non-Secure HTTP
#305Re: Deprecating Non-Secure HTTP
#306Earlier 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.
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
#307Earlier 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 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.
Re: Deprecating Non-Secure HTTP
#308Earlier 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.
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
#309Mentioned 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.
Re: Deprecating Non-Secure HTTP
#310Earlier 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).