Life Is About to Get Harder for Websites Without HTTPS
troyhunt.com
troyhunt.com
Imagine someone who knew enough to set up a site on his own server a long time ago and had left it alone ever since. Maybe he'd considered turning it off a few times, but just couldn't be bothered to. Now he suddenly gets contacted by a bunch of people telling him his site is "not secure". Keep in mind that he and his visitors are largely not highly knowledgeable in exactly what that means, or what to do about it. It could push him over the edge.
...and then there's things like http://www.homebrewcpu.com/ which might never have existed if HTTPS was strongly enforced all along.
I understand the security motivation, but I disagree very very strongly with these actions when it also means there's a high risk of destroying valuable and unique, maybe even irreplaceable content. In general, I think that security should not be the ultimate and only goal of society, contrary to what seems the popular notion today. It somewhat reminds me of https://en.wikipedia.org/wiki/Slum_clearance .
(I also oppose the increased centralisation of authority/control that CAs and enforced HTTPS will bring, but that's a rant for another time...)
Installing LetsEncrypt is not much work and he might be motivated if a lot of people ask him. If he is really not interested, it is probably best to archive the website to a real archive and hope they make sure they content remains available. Unfortunately this also means that the archive will no longer be found on google or most other search engines. It is really a shame that there is no work on google's side to make sure archived content can be found among other search results.
Assuming he has direct access to his server of course. If he's on a shared host, he may not have the option to use LetsEncrypt, but may be forced to a buy a certificate from the hosting company.
"Not secure" doesn't mean you have to shut it down, it just means it's not secure.
This is part of a trend of gradually increasing production values for mainstream sites; it makes the less polished stuff look dated, but in a way that's just going back to the old days when the Internet was an obscure place with a small audience.
That being said, I think the owners of sites will still feel the sting in their gut seeing or hearing their site is insecure or that browsers are scaring visitors away...so I think it will speed up adoption even further and I do agree that https will become the default.
The feature got removed recently from Chrome and Firefox - why?
In older FF, Chrome and still available in IE11 you just click on the "secure" icon next to the address bar.
I am really the only one who misses this feature?
But why hide it so that normal web user can't access it?
Checking what Cert-company signed the certificate is important to trust a site.
Before it was one left click and it showed the company that signed the cert (optional you could view the cert itself)
Now many steps like click on hamburger button -> More tools -> Developer Tools -> Security tab (bottom of screen) -> View Certificate (shows certificate itself)
What a trainwreck of decision t remove this vital info. e.g. YCombinator cert is from "Comodo". If it's suddenly from a funky else it would help lessen the trust.
I am sure, it was just a mistake to remove it and some cargo cult.
Old myspace pages? Geocities? Old BBS boards?
- when I log in to my webcams it says the connection is not secure
- when I log in on my nas it says the connection is not secure
- when I log in on my router it says the connection is not secure
- when I log in on the web interface of mythtv it says the connection is not secure
- when I log in on my self hosted gitea instance it says the connection is not secure
- when I log in to my self hosted nextcloud it says the connection is not secure
- when I log in to the configuration page of my toaster it says the connection is not secure
All these things are on my lan, and on most things there is no way to install a tls cert on them, nor would I want to do that.
Firefox already nags me that the connection is not secure when i enter a username and a password in any of those sites.
[citation needed] - I would say most people will primarily use LAN services in private home/corporate networks. But I don't have a citation either.
It's different use cases. Maybe one needs the warning, the other one not. But putting the warning on everything and overload the user with them is not the right solution.
Using a self signed CA is a pity, because installing it on every phone, tablet, laptop, tv, pc, ... is cumbersome in a home network, and making all hosts public and depending on an external CA for local resources to not get scary warnings can not be the right solution either.
Sorry I don't have a citation here. But looking at my coworkers and family, none of them uses services in their home LAN. Most won't even know how to access the router.
On the other hand it's very common to use Wifi in public transport (at least here in London for the tube), airports, trains and hotels. Few people consider security when using these hotspots, making sure that SSL is enabled for all pages would be an improvement.
But do you use LAN services on that network? I think you will use that public hotspot to check facebook, hn, search something on google and stuff like that, not connect to some service in the local network of the hotspot.
They don't have printers? They don't connect to a NAT router before their cable modem? They never tether their computer to their phone? Their DVR doesn't have an app to control it? None of them have their receiver connected to their iTunes library?
For instance (to draw from your examples): 1) Most people either install the printer drivers from the manufacture's web site, or let Windows/OSX auto-discover and auto configure the printer with out a web browser. 2) Most users just use the wifi information provided by the cable/DSL provider when they installed the modem, use the WPS button, or install the app that came with their router rather than use a web browser to configure it. 3) Most users will not tether their computer to their phone. 4) Most don't install a DVR app on their phone. If they did, their phone probably communicates with their DVR via some intermediate cloud service. 5) If their receiver auto-connects to their itunes library, it probably won't complain about that itunes not having a public certificate either.
There's a clear divide that I see daily between households that understand their tech, and households that simply use whatever was set up for them. That divide seems to be growing wider, lately, too ...
Maybe this helps forcing companies of IOT-like devices finally take security a bit more serious.
Browsers, rightfully so, don't accept self-signed certificates. Active Directory and Group Policies can push out a trusted self-signed root CA certificate and generate certs that endpoints can use, but that's a pain in the ass and usually requires central IT to manage.
Please someone come up with something I haven't thought of yet that doesn't break the internet but gets useful certs onto my LAN!
Why? What's the threat model, that your employer/colleagues can see your traffic?
We are rapidly moving away from perimeter solutions and toward zero trust networking models. Yes, you should encrypt and authenticate inside your LAN.
The browser will still let you choose. It's just changing the default.
> For example in my home network I have different vlans: one for things i reasonably trust, and one for the chinese webcams and iot lightbulbs.
Congratulations, you are the 0.0001%.
> If my router has malware, even if i talk to it over https I'm screwed anyway, I don't think that is something I can fix with https.
Right, but if your lightbulb has malware and your router doesn't yet, then using HTTPS while talking to the router is pretty important.
I agree. So what's the solution you propose?
- Using a self signed CA that you have to install on all your devices?
- Using a trusted by default CA, that makes your internal-only devices depend on an external service (the CA)?
Or something else?
I'm not saying that encrypting the traffic in a LAN is useless. I'm saying that https and the current CA system is not the solution.
This one. Realistically all those devices are depending on external services already.
This is codifying (IMHO) bad practices and a really brittle architecture. Why would you want this? One of the reasons IoT security is a mess is that devices need to talk to internet endpoints instead of staying inside the NATted, firewalled LAN.
Say ports 1-4 on the switch are your trusted devices, 5-8 are your untrusted, and 9-10 are the LAN side of the router. There are other ways to do it but this is probably simplest and easiest to mentally map. Set ports 1-4 and 9 as access ports for VLAN 100. Set ports 5-8 and 10 as access ports for VLAN 200. Now you have two virtual networks hooked into one physical, partitioned by the router.
You then set up eth0 (port 9) as trusted LAN and eth1 (port 10) as untrusted LAN in the router, and give each an IP range (Separate subnets at a minimum). Now all trusted can talk to each other and all untrusted can talk to each other, but nothing together yet.
You then set routes and rules (port filtering, SNAT, DNAT, etc) for port access from either network to the other to finely control what ports are available to what. You do the same thing with eth2 which would be the connection from the router to the modem for internet access.
Not a full tutorial but hopefully that points you in the right direction.
Now a small group tries to break the web and enforce HTTPS, but why? Is it to de-anonymize the web users?
And if your answer is "sure, but there will be other websites that are HTTP" my response is "yeah, but one day soon when enough of the web is secure I'm going to disallow all HTTP connections from my browser". And eventually I'll disallow all connections that aren't on HSTS preload lists. And eventually, hopefully, I'll disallow websites that don't have HPKP with long expires.
I doubt HPKP will ever see wide adoption. At least not in the form it has now. It's just too damn easy to bork the config and take your entire site offline with no way to remedy that error.
Many moons ago I was using a proxy engine capable of unpacking/packing HTTPS requests.
It was an in-house proxy taking advantage of Apache and IIS APIs for certificate management and SSL connections.
We used it for debugging secure connections, but I can easily envision other purposes.
Many years have passed since 2000, but I am quite sure it is still quite possible to do it.
In short, you can intercept the traffic, but it relies on the client explicitly trusting your certificate. This is the foundation of all security on the web.
We weren't using an off-the-shelf proxy, rather some nice debugging tools with extra help from the networking layering.
Maybe TLS is more full-proof to Website replication with DNS spoofing and a few other tricks, but they did work without issues in SSL 1.0 connections, using modified web servers.
These days the only viable way to MITM HTTPS is to either attack the connection while it's in plain text HTTP (ie before the browser redirects to HTTPS:// (which is where the HSTS header comes in to play - it's cached by browsers telling them to default to HTTPS and never attempt a plain text connection) or to form your own HTTPS connection with your own CA signed certificate for the target site. Which would mean you'd either need to compromise a signing authority or have your own CA certs already installed on the victims PC (the latter is what some bad ISPs reportedly do when they inject ads).
Edit: I believe some corporate network proxies also work on the principal of having their own CA certs on their business workstations - so maybe this was how your proxy worked as well?
That information eventually needs to be unpacked, so you get a replicate of the destination site with the same certificates, which you can easily download by pretending to be a browser, but running on your modified server, which then unwraps, repackages and then forwards the request to the original server.
Since one owns the server, it is also relatively easy to disable whatever validations the SSL algorithm requires at library level.
So I don't know TLS and since 2000 I don't mess with this kind of stuff, but I don't think similar approaches aren't possible.
The only way they can succeed in proving who they are, is if their server has access to the corresponding private key of the certificate, which is why you can't spoof a properly secured site unless you either hack their server, crack the encryption, or install your phony certificate on the client (which is what corporations sometimes mandate). That's it.
It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).
If what you state is true, now in 2017, then there would have to be a huge conspiracy which involves all browser vendors (including Mozilla), as well as all national governments and the EU that hides this fact from the people. All software developers who do catch on (the relevant source code is open source after all) would have to bribed or threatened into silence too.
You are either misinformed or consciously spreading misinformation.
The workaround for that is to create your own SSL certificate for that website (this will create you a public certificate and private key). Which means you will also need that new certificate CA signed otherwise the client (who's own SSL validations you cannot remotely disable like you implied) will give the user a warning about an untrusted certificate (the message will vary from client to client). This means you either need access to the targeted client to install your own CA certs, or you need access to a compromised signing authority.
People who can MITM you when you use HTTP: any entity on e.g. http://www.bgplookingglass.com/list-of-autonomous-system-num...
For this reason I used a VPN while travelling overseas. Most places have wifi of varying quality. To my dismay/horror, I found that Hilton charge EUR15/day for the privelege of using a VPN.
Every website should use HTTPS. It's the right thing to do. It's not hard to do these days.
Unless you use simple tools like GitHub pages. I have a bunch of tiny JS heavy static projects on Pages that I can't easily add HTTPS to.
There are legacy setups like S3 with custom domains, probably github pages with custom domain. But in both cases there is no reason not to be using cloudfront or cloudflare.
I understand that's not technically "your problem", but since you mentioned it, just thought I'd let you know :)
It's unfortunate, because tumblr really is a great blog hosting software and service, if you don't use the social aspects of it.
But these aren't technical limitations! I don't know why Tumblr retricts you from using cloudflare, presumably because they want to control your content.
My two cents, don't use a free hosting service. S3+cloudfront is dirt cheap and will do the trick.
I'd rather deal with the very occasional “why not secure?” e-mail rather than pretend my site is actually secure. (I only serve static pages, not forms.)
And regardless of that it offers privacy for your users.
Beyond privacy it also vastly improve security too, since users are most likely to have malware and ads injected by an infected wifi router.
It also increases complexity of an attacker that has control of the local machine, since they'll now have to install a custom root certificate.
Nothing is perfectly safe, all we can do is raise the bar.
A current project of mine has some usability issues because it accepts external API requests but I won't allow non HTTPS. It would give me great pleasure to accept all possible APIs, but it's just not right to open users to that risk.
It's not really that hard. Set up auto-renew, make sure the box is up to date and properly firewalled. You won't really have to think much about it.
My main concern with this happening is that browsers are going to get a reputation for being 'alarmist', so when something really goes wrong, they won't be able to communicate it effectively.
Yes, search engines will penalize you. ISPs will intercept traffic and change it. Your site will load slower. The problems with plain HTTP go on and on.
> all websites with form fields served over HTTP will show a "Not secure" warning to the user
As long as you don't have a form field, you should be fine.
TLTR: if you have a commercial service or device running in a local network forget HTTPS and service workers, use HTTP and HTML5 appcache.
-- RANT starts here --
It would be lovely when every website and webapp uses HTTPS. But for a significant amount of them it's just not f..... possible without driving users completely insane.
If the HTTPS server doesn't (and never will) have a public domain forget about encryption and security, forget about using service workers. The following examples can't, by the love of god, ever provide HTTPS without completely f..cking up user experience due self signed certificates warnings:
1) internal corporation services, websites and webapps.
2) services that run in a local private network like on a Raspberry Pi.
3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services, like to a Philips hue bridge, or any other IoT device which is in the local network but only provides HTTP. These will enlight the users with a shiny mixed-content warning.
.... JUST use self-signed certificates, they said.
NO.
For normal users the UX of self-signed certificates is just non existent, it's a complete mess! It will scare the sh't out of users and will almost always look like your service is plain malware.
It looks much more secure to serve a good'ol HTTP site with no encryption at all.
If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? And how would you feel if people on the same LAN could see and modify all your interactions with those services?
2) services that run in a local private network like on a Raspberry Pi
Depending on the type of service you may or may not want TLS. If you visit the service by IP address and specific port anyway, you can easily add an exception for your internal IP. This will never be used like so by non-tech-savvy people.
3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services
I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting.
Don't blame browsers for warning people for their insecure systems and appliances. Instead blame their creators or manufacturers as they're the ones who can fix this situation.
edit: formatting
The Philips hue bridge REST API is accessible in the local network like http://192.168.1.123/api/ .... which is great since apps/wepapps can talk to the bridge without a cloud or philips server inbetween.
And this is the very problem, it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge.
Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
Which in my case is a webapp running in a browser :)
I'm surprised they even allow such cross-domain requests, but this anyway doesn't seem safe.
Disallowing unsafe websockets from secure origins is one of those policies that is a really good idea 99.5% of the time but for those last 0.5% of use cases, it's a major pain in the bum.
[0] WeeChat has a /exec command to execute arbitrary commands, and the client has access to that --- not great when you transmit your password in plain text.
I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make.
> Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device.
The simple fact that you accept some insecure traffic, doesn't make it secure.
> I don't see why not.
That's not a constructive argument. I don't see how they could make it work?
Even if they somehow solve the problem of giving these devices domain names and even if they generate separate private key for each unit, the key and cert are going to be embedded in the firmware and a sufficiently sophisticated attacker will just extract them and become able to impersonate some Philips device.
How the user of another device is going to tell whether he is connecting to his device or to malicious neighbor impersonating neighbor's device to establish Philips-signed HTTPS with the victim and then another connection to victim's device and MITM the victim?
You would have to make all users install a trusted certificate authority tied to their individual device. Which is a UX disaster in current browsers and also a security disaster, because if this becomes a norm, sooner or later somebody will sell you a toy device bundled with a CA crafted to give him the ability to impersonate any website. And you'll trust this CA because you want to play with the toy.
This maybe could be made to work with some improvements in browser UI. Make it easier to add new roots of trust. Make it easier to learn and/or limit what websites these certs will be authorized to authenticate. But nothing like that exists now.
> The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. [...] The simple fact that you accept some insecure traffic, doesn't make it secure.
True. As somebody pointed out elsewhere in this thread, this warning will become another EU cookie banner nothingburger.
> > I don't see why not.
> That's not a constructive argument. I don't see how they could make it work?
Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices.
If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist.
The original issue is that having a public website (used over TLS) that interacts with local network devices without TLS shows warnings about insecure communication. Again, the warning is shown because it /is/ insecure. There are plenty alternatives of securely interacting with an IOT device. Plain HTTP from a public website is just not one of them. For example, look at how Apple's Homekit has implemented that. Homekit is not usable from a public web page in a web browser. That's a good thing. (aside: I'm not a big fan of Homekit but their security is not bad)
So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers.
> sufficiently sophisticated attacker will just extract them and become able to impersonate some Philips device
Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?)
I don't see how they could make it work?
Of course, you have to get a special deal from a CA at who-knows-what-cost - likely meaning open source projects need not apply. And you get a dependency on cloud infrastructure, if they stop issuing certs you end up in a bad place. And you get a giant, ugly URL. And you have to make a DNS lookup so traffic leaves your network anyway.
It's an ugly solution with a lot of downsides - but I doubt the CA/Browser Forum plans to give people much choice in the matter, so it's their way or the highway :-|
[1] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
Give each one a subdomain that resolves to its local IP, and give it a valid certificate for that subdomain.
> extract them and become able to impersonate some Philips device.
Or the attacker could just have a real, non-impersonated Philips device. If the user deliberately points their browser at the wrong device's site, nothing can save them. This is a very different problem from securing access to the correct site.
> You would have to make all users install a trusted certificate authority tied to their individual device.
That's not true, and I don't even understand what benefit that would have.
If you have a way to deliver a CA, instead you should deliver the correct address of the device. This makes 'MitM' impossible without any downsides.
What if they'd just ask the user to accept and install a certificate when connecting to a local server for the first time?
Well then please explain how this is possible?
If you control physical hardware, and you control all the users on it (as a corporate network), then you can know that nothing is amiss.
>And how would you feel if people on the same LAN could see and modify all your interactions with those services?
The fact that they physically can doesn't mean they will.
For 2 & 3:
https has two modes: self signed, and certified. Certified requires that you have a public facing domain name, such as "news.ycombinator.com". Devices on private networks can't have public domain names. Consumer devices on public networks could have domain names, but this would be very difficult to configure. Without a domain name, https must be done as self signed.
With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. It should be clear that you can still be MITMed under this mode, so long as the attacker can intersect the first message you send after a reboot. If you're scared of network ninjas sneaking into your house in the middle of the night and intersecting your packets, self signed https is no better than http.
If I create a CA and install that CA's public key in my browser, then use that CA to sign the cert for a device on my network, why exactly will it "be anyone"?
Unrelated, but this push for HTTPS for everything isn't without downsides. Many apps gather extensive data when running on my devices and they communicate that data back to some central location, sometimes under the guise of functionality, sometimes straight up nefariously, but always with a side effect of giving that central entity a complete record of what I'm doing and often also exfiltrates my data (contacts, etc.)
Honestly, I've been tempted to set up a transparent TLS terminating proxy at my home to give myself some possibility of seeing wtf is coming and going from my network.
Because a crap ton of Linux software comes with its own set of bundled root CAs instead of using the system defaults. Welcome to the configuration nightmare that is setting up Anaconda, npm, AWS CLI, Python (Requests library), Git, etc. for working with something like Zscaler.
The issue is that Zscaler may have flaws, and that even if the validation is performed flawlessly then the introduced risk is not zero…
Usually one would have to trust the root CAs, but with TLS interception we have to trust the trust of the MiTM software in the root CAs. This increases the attack surface instead of decreasing it.
For a security appliance it’s a pretty bad job; sure, there may be reasons why you want to look into traffic, but then the aim is to control the communication. And control doesn’t come for free.
For this use case companies usually provide an internal CA, which signs their certificates and is trusted by all company machines. We have various customers which do this and it works just fine.
Small companies/small groups of developers have no idea how to implement and manage this, but think that it should be easy.
I've recently been approached by a group of developers to enable SSL on their internal sites. When I mentioned that this would take some time, the response was "why can't you just use LetsEncrypt?"
I replied that LE only works on external facing sites, not internal sites. The next response was "fine, why don't we make it all external facing?"
I'm still trying to explain that their CI server (Jenkins, with its history of remotely exploitable vulnerabilities), and their internal OAuth2 server should not be public facing.
But yeah, don't expose Jenkins to the Internet directly. Last month I saw a Jenkins instance that was mining bitcoins. The worm had used one of Java's serialisation vuln to get in the box and install the miner.
LE supports DNS validation; as far as I'm aware it now works great for internal sites.
Not so many years ago, Microsoft recommended that organisations used [companyname].local as their internal DNS zone[1], as .local will never be an external zone, so there would be no conflict. Then along came cloud integration and increased need for edge services, and .local no worked well as a solution. Servers needed certs with both the local domain and a new external domain in their certs which became a security nightmare. Then (about a year ago) CAs stopped issuing certs for domains that weren't sub-domains of proper TLDs, which all but killed the concept of these internal non-legal domains.
So, unless you are prepared to roll your own CA, AND instruct your internal (non MS-domain members) users how to manually install an untrusted cert, signing internal sites that do not have a legal domain name, is a complete non-starter.
---
[1] Now of course they recommend a sub-domain of your public domain name (site1.company.com), or a reserved public domain name that you don't use externally (site1-company.com). Which is all well and good, but what about the 100s of legacy kit you've got on the old name... ~sigh~
And you don't actually have to expose it to the internet to get a certificate, you only have to give it a public name.
Using a proper FQDN for each service only makes everything easier to maintain.
e.g. my company uses *.int.cuvva.co which all point to IPs in the 10.0.0.0/8 block, but we still have HTTPS certificates for all of those.
No, you just need to have a public DNS entry, no need for that service to be reachable from the internet.
foo.example.com can resolve to your private RFC1918 address, when you send the CSR to a CA, they'll verify your ownership of example.com.
You don't need to expose your server to the public internet to use let's encrypt. I use DNS authorization and it works perfectly.
I actually have all webservices in my home network secured by https, all you need to do is click a cheap vps, install nginx and tinc, and then proxy /.well-known/acme-challenge/ to your internal servers. Either setup domain or ip hijacking so the public IP is routed inside your lan. Done.
If I can do this for me and my cat in my spare time, you can do this for your university.
> need to expose critical internal services on the public internet, some of which contain private user data.
The heck? Are they aware of this? Might you get sued for this?
2) with regards to raspberry pi, will anyone who can write code can learn to also create their own CA the only difference is probably no automation of adding to the trust store likely however it is only a 2-3 click install in most cases.
If I were to choose everyone would be using public domains with DNS zone view for public / private environments but Microsoft DNS service don't even support it.
Also why do I get a certificate warning that looks the same for an IP (https://192.168.1.1) which you can not buy certificates? What about 10.x.x.x or even 127.0.0.1? As far as I know you can also no longer purchase a certificate for public IPs.
Just watch how consumer router manufactures are going to work around this by either re-educating their users to ignore the red warnings or only selling cloud managed and locked devices which sucks for everyone.
Configure the LAN setting of RT-AC68U. Device Name: ghandi
I'd prefer that Chrome write "insecure" if there's a non-public CA in your chain.
1) Every employee of every company needs to have some level of trust in their company. They trust their company to make payroll, and they trust their company at a reasonably high level to follow local laws and regulations, including reporting threats and violations against their physical safety. That doesn't mean that employees should trust their employers with their deepest darkest secrets and life savings, or that there aren't different types of trust, just that trust is a spectrum, and arguing that you should fully trust every one of the shadowy public CAs pre-installed in your OS and browser, that you know absolutely nothing about and have not personally vetted nor have personal relationships with, but not the intranet CA your employer operates, is rather clearly an irrational assertion.
2) If you decide not to trust your employer's CA, and your employer has provided you with a machine to access intranet sites, then you clearly cannot trust accessing Internet sites for personal reasons on your employer-provided device, not because the CA cannot be trusted but because it's irrational to distrust the CA but also trust the employer-provided device, which may have a keylogger and other tracking software installed.
3) If you decide not to trust your employer's CA and your employer operates a BYOD environment, then you are free to bring a separate device for work purposes, on which you trust your employer's CA but refrain from accessing personal accounts, instead only accessing personal accounts on devices which your employer doesn't know about.
If it's BYOD, then create a new user account / profile for work. We're not running DOS anymore.
HPKP does not validate pins if they resolve to a user-installed trust anchor like an intranet CA. The RFC [1] leaves behavior undefined (see Section 2.4), and I'm not aware of any popular implementation that would honor the pin in case of a user-installed certificate.
This can be incredibly frustrating if you're trying to protect against MITM attacks; but at the same time, I can follow the browser developers' line of thought that goes "if we were to enforce it, users would just jump ship to the next available browser".
Commonly I only allow internal CAs for specific internal websites and not allow them to MITM just any website. On occasion this meant not being able to use the company's wifi and deal with 4g instead.
Certificate errors on "internal" web apps are just as bad as on the rest of the internet.
If I have to I trust the company's CA in a special browser profile that I only use for working with their internal tools.
For just a few tools it's often simpler to just trust those specific certificates, though
Then give it a public domain, keep it on a private network, and use a real certificate?
Not for long it won't: Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.
Taken from Google security blog[1] back in Sept 2016: https://security.googleblog.com/2016/09/moving-towards-more-...
If this is an internal corporation service, why don't you bake your own self-signed root certificate into every computer in your network? Then you can generate as many certificates from your own root as you like, and they'll all magically be valid on corporate computers.
That one's straightforward. Set up a corporate CA and use it for your internal certificates. Or, operate your corporate services on your real domain name, and use real publicly-trusted certificates - whichever is easier.
Good luck with Docker containers running any Unix software that bundles the "default" root CAs along with it.
On the docker side (or rather on the reverse proxy that provides access to them) you are solving different problem and it does not matter whether the key/cert is provided by your internal CA or third-party one.
FROM kanboard/kanboard:stable
ADD ownca.crt /usr/local/share/ca-certificates/ownca.crt
RUN /usr/sbin/update-ca-certificatesHave every local machine get something that is internet-routable to a public machine that allows you to get a certificate, then on your corporate DNS, just serve the local machine it's supposed to go to and you can use that cert.
You could use Let's Encrypt for this and have free certs.
https://community.letsencrypt.org/t/does-lets-encrypt-has-li...
(but yeah your points are valid, which is deeply unfortunate)
When firefox started throwing warnings on my intranet sites that are accessed via OpenVPN i did this:
1) move all internal sites to valid FQDN 2) push dns settings over openvpn so that clients resolve the names with the internal dns service and dont leak names. Names withing the vpn resolve to internal ip addresses. 3) set up a catch-all website, point the wildcard *.company.name domain to it and mada letsencrypt certs for the internail domains/ 4) copy the valid certs to the intranet webserver. Done. Everything working ok.
Do I agree with this signal? Not entirely. But the company was forced into restart and into new management. Guess what colour their lockboxes were?
The default has shifted; if your best retort is "it's hard," I'm not sure what to tell you. Yet government, maybe?
I'm a software engineer with a smidge of basic networking experience so not completely clueless, but definitely inexperienced with DOCSIS and this sort of residential networking stuff.
Here in Germany, you no longer get IPv4 addresses from Unitymedia.
It seems more important than ever to roll out IPv6, since, at some point, IPv4 is going to become incredibly scares. Imagine a permanent/reserved IPv4 address on DigitalOcean/AWS/Vultr going from the few dollars a month to $70/month or $100/month. Forget network neutrality, regular people won't even be able to host their own content in a way everyone else can reach.
But I expect things will continue slowly being replaced, as more switch over the stress on IPV4 lowers.
IPv6 is certainly necessary but nothing users have to worry about.
The success of "Let's Encrypt" suggests that a key part of the problem wasn't a lack of user complaints about security. Rather, it was a lack of a sane model (both technically and economically) for setting up and maintaining certificates. In the end, people maintaining sites already had 100 other things to worry about and weren't going to get around to HTTPS with anything less.
It's a "better than nothing" option, as there are a slightly higher number of actively exploited attack vectors that apply to the client to CDN connection than the CDN to origin server, such as "free" wifi that injects ads, malicious ISP DNS, and the like. But it's not actually secure, as the origin server to CDN connection could be tampered with, and just because there are fewer active attacks that would be likely to affect that connection right now, doesn't mean that someone won't come along later and hijack such a connection.
CloudFlare offers other TLS options that do include encryption and authentication between the origin server and CDN, but they do require that you set up a certificate on your server, so if all you're trying to do is enable TLS (and don't care about the CDN), just installing a cert on the origin server and using TLS is probably a simpler option that using CloudFlare.
It's great that shared web hosting providers and others are starting to make it easy to acquire and install a certificate, but that hasn't always been the case.
EDIT: We also provide an API that will provision a free certificate for your origin: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/. The certificate is optimized for communication with our edge (essentially just as small a chain as possible, as we don't need the intermediate to walk to the root). Either that or use certbot from EFF/Let's Encrypt.
Troy Hunt (OP) discusses this at length in this post => CloudFlare, SSL and unhealthy security absolutism https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-securi...
End users won't be configuring their own servers anyway. At best they'll get a cPanel (which using AutoSSL, can then support Let's Encrypt).
location / {
proxy_pass http://localhost:8082;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Forwarded-Proto $scheme;
}
Any host that still requires a dedicated IP for https is woefully out of date.
May be true in a perfect world but this is my web host (bluehost):
>> Note: Since SSL Certificates are Domain/IP specific, you must first Purchase a Dedicated IP before purchasing or having an SSL Certificate installed on your account. They will NOT work with a shared IP address.
I'm pretty sure a lot of other hosting services still go that route.
Bluehost US doesn't seem to, as you indicate - https://my.bluehost.com/cgi/help/473
I'm not sure whether they just don't support SNI yet, or whether they are artificially enforcing this restriction so that they don't have to deal with IE6 not working.
Edit:
A quick search seems to indicate that the only typical consumer facing system that doesn't support SNI is IE on Windows XP. It's pretty safe to have a catch-all bucket that informs such users to use a modern, security patches including browser or to upgrade to a different OS.
Eventually old clients have to be let go of, maintaining compatibility for them degrades everyone else's security.
If this is truly disconnected from the Internet then yeah HTTPS is unsuitable - it fundamentally relies on the idea that there's a central, universal definition for who owns "foo.com" so that users can rely on talking to the correct "foo.com".
i.e. it'd be config.linksys.com and that'd point to 192.168.1.1, but have a certificate that matches the one on the router.
The public DNS record is needed to verify the DV cert, not to do the actual lookup.
This is because the device would have to ship with the private key.
Say you have a plain Debian 8 install, running a typical LAMP stack serving a single domain.
If you want to make it use a LetsEncrypt cert and serve the domain over HTTPS - what would be the minimum number of steps on the command line to make it do that?
apt install letsencrypt
letsencrypt certonly -d example.com -d www.example.com -m you@example.com --agree-tos
letsencrypt renew
I've pushed for the 3000+ websites to be served over HTTPS but there's serious reluctance from the sys admins about creating and managing such volumes of certificates. So I'm guessing it's easy if you only have a handful of services, but at volume it becomes a little tricker. If there's a easy way to solve this problem, I'd love to hear it.
Non-interactive: install Certbot, copy the config file, run certbot, add a crontab for renewals, configure your nginx to see the certificate.
Edit: typo
<script src="https://cdn.example.com/awesome.js">
Automatically generated self-signed certificates should have replaced all plaintext HTTP 15-20 years ago. The big security hole was allowing passive surveillance, ISP-level page injection vandalism[1]/attacks[2].
The web could have been almost completely protected from several classes of attack a decade ago, but this stupid insistence on conflating protection from 3rd part eavesdropping or corruption during transit with the authentication of the server. These are entirely separate problems that do not need to be solved at the same time.
> I am requiring the script to be served securely
You're requiring it to be served over HTTPS, which doesn't necessarily mean "secure", because "secure" covers several different goals. You're also strongly trusting the PKI system. Do you trust all the certificate authorities your browser includes by default?
Of course, because HTTP still exists, the initial request for the HTML that contains your <script> tag could be sent plaintext and thus modified during transit in many different ways.
> serve a malicious script to my users.
That can still happen without proper pinning, or if the local browser downgrades the request back to HTTP. Unfortunately this isn't particularly uncommon with corporate/school proxy, in-flight wi-fi services that forge certificates[3], and Superfish-style junk all removing both the encryption and the authentication provided by TLS.
Regarding your specific example about loading Javascript referenced in an HTML document's <script> tag, the solution is to validate the data, not the server. The valid server can still send incorrect data. If you include hashes about a page's subresources[4], the browser can validate the integrity of the file it received.
[1] https://arstechnica.com/tech-policy/2014/09/why-comcasts-jav...
[2] https://citizenlab.ca/2015/04/chinas-great-cannon/
[3] https://arstechnica.com/information-technology/2016/02/why-y...
The client can detect changing to a new certificate. Obviously self signed certificates have problems. The main point is that it does protect against some attacks, and raises the complexity/cost. Running a MITM takes a lot more time, effort, and resources compared to simple deep packet inspection on plaintext packets.
> Without the verification by public CAs
While there isn't much support in current client software, verification doesn't have to be from a CA. In an ideal world, your bank (or whomever) could hand out some sort of dongle (or maybe as a QR (or similar) code on a card?) that had a certificate that could be used for direct verification of their internet services independent of any CA, or in combination with CA verification.
Not if the client has never visited the site before and doesn't have a known-good self-signed certificate pinned locally to check against. And if the client did have such a certificate pinned, revocation by the legitimate owner of the self-signed certificate becomes impossible, since the client won't trust the new self-signed certificate being presented to it, without out-of-band communication of said intent to revoke and manual intervention on the client side.
> dongle
Again, the problem is certificate revocation. Physical dongles cannot easily be revoked. Corporate intranets deal with catastrophic compromise of their internal CA certificates by re-imaging all corporate machines with new certificates and restoring from off-site backups where needed - prescribing that for customer machines is impossible.
PKI is like monitoring - it must rely on external services to be dependable and effective.
What? What kind of browser would downgrade the request to HTTP?
Unfortunately this isn't particularly uncommon with corporate/school proxy, in-flight wi-fi services that forge certificates
Which require a cert signed by a CA already in the client's machine.
Regarding your specific example about loading Javascript referenced in an HTML document's <script> tag, the solution is to validate the data, not the server. The valid server can still send incorrect data. If you include hashes about a page's subresources[4], the browser can validate the integrity of the file it received.
If you don't have HTTPS, how can you be sure that the SRI hash wasn't tampered with?
Sorry, that should be the browser's local environment, not just the browser itself. An obvious example is sslstrip:
https://moxie.org/software/sslstrip/
> Which require a cert signed by a CA already in the client's machine.
Of course. That happens.
> If you don't have HTTPS, how can you be sure that the SRI hash wasn't tampered with?
Loading static resources from other domains is very common. Especially ad networks.
Right. Which would still work if all HTTP connections were replaced by HTTPS with self-signed certs, as you proposed. sslstrip, which must have MITM control to do that downgrade, would just terminate the connection and re-encrypt it with its own cert.
Which is why PKI HTTPS everywhere is the reasonable solution.
Of course. That happens.
Right. Nothing can protect you if you deliberately undermine it.
Loading static resources from other domains is very common. Especially ad networks.
Right, and SRI is certainly useful, but you still need PKI HTTPS on every site to bootstrap it. And since the only reason to avoid HTTPS is to avoid the encryption penalty, automatically generated self-signed certificates wouldn't be used anyway.
In the not too distant future, they will be, though perhaps not in the way you had in mind: HTTP sites will start showing similar indications of insecurity, just like sites with broken HTTPS.
It's all true. However, I would make the case for Pat Q. Mainstream feeling less alarmed by "Not Secure" messages than most HN readers.
Note the Twitter example is from Mr. Hunt, not a random internet user.
> Page is an ad for Mr. Hunt's
> $299 course
The article that seems to stick in my head is him spruiking a wifi extender he got for free so he can access wifi on his jetski at his jetty.
https://www.troyhunt.com/how-i-finally-fixed-the-dodgy-wifi-...
I can't bemoan how many times I've had poor wifi at my jetty ;)
A modus operandi is someone's habits of working, particularly in the context of business or criminal investigations, but also more generally. It is a Latin phrase, approximately translated as method or mode of operation.