Chrome 68 Released: HTTP Sites Marked as “Not Secure”
chromereleases.googleblog.com
chromereleases.googleblog.com
Now it reflects the real world better: HTTPS is necessary but not sufficient for security, but with HTTP only you definitely don't have much security. I guess that's the best you can guarantee or communicate via the browser UI.
This doesn't stop companies and many individuals calling HTTPS "secure".
You are right but when the protocol name says 'Secure' right in its name, no wonder people market it as 'Secure'.
Let me clarify that I don’t object to encryption - I object to telling the user “this site is secure” when there is no way to know that
Nothing is sufficient for total security, but "HTTPS everywhere" is a vast improvement, going from zero security to almost sufficient security over night.
Unfortunately, it's both. Otherwise we would have had widespread encrypted connections decades ago. I'm not sure why browsers decided that no encryption is just fine, but encryption with a self-signed certificate triggers warnings that it's the end of the world.
I mean, I know Plex has an arrangement where they provide a dynamic DNS style record and they have a special deal with Digicert to issue loads of wildcard certificates [1] but that needs a bunch of infrastructure and a special deal with a CA, as well as precluding offline use and breaking if the supplier ever drops support.
And obviously, you can also use a self-signed certificate - but that means teaching users "Just click ignore on the invalid certificate warning" and I've heard people say we shouldn't train users to ignore invalid certificate warnings.
Is there some alternative solution Google is proposing?
[1] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
But there is no meaningful way to make it secure. So marking it not secure creates just noise.
It's informative: you might not be able to do anything about it, but you should know it anyway.
If the same thing happens in my local lan I don't want the same warning, because if I get the same warning I will start to ignore it, and not only when I'm in my local lan.
Parent comment was talking about routers and network printers. No CA (except for if you're your own CA) would provision a certificate for "192.168.0.1" or "hp-laserjet".
Insecure LAN resources should be probably treated differently from just "secure/insecure".
If you are talking about networks that are air gapped from the internet, you would have a problem anyway with the short letsencrypt expiration times, and you will in any case need to do all kinds of hoops that are bigger problems than installing a local CA or settling for a "insecure" browser warning.
(Also LAN doesn't automatically mean rfc1918 addresses for many people, and getting less so all the time with IPv6 deployment coverage)
If I must choose between the possibility that an attacker with local access might snoop/change my printed documents, and a possibility that my printer will become part of the next botnet through some firmware exploit, I'll definitely choose the former.
Letsencrypt doesn't require you to run a public facing web server on that domain, you can use DNS challenge validation where you prove control by putting a TXT record in your domain.
printer-level0.printers.coorp IN A 10.10.10.10
Also, my school has so many IPs that they do give public IPv4 addresses to all machines, printers, etc. but block access with a firewall.
Adding a name->address mapping for a private address doesn't magically make the private address globally routable.
You being able to see that my.internal.web.server.domain.tld maps to 192.168.43.123 doesn't mean that you can see that web server from your location.
Even if it was actually a directly routable address rather then one sat behind NAT it wouldn't be accessibly unless I'd expressly added a rule for that in my firewall to override the default "no access from outside unless some other rule has stepped in" rule. And this isn't a DNS issue either: even without the name that address would still be exposed with a bad firewall setup.
hp could get a cert for 15327c5ba80d1b8933.hp.com and make it resolve to 192.168.0.5 (your printer).
Or use addresses like https://192-168-1-1.hp.net (https://192-168-43-123.hp.net, https://10-20-30-40.hp.net, and so on) and a wildcard cert. No harder to document than telling people to go to http://192.168.1.1.
Though they should be more careful than to use to top-level domain as they need to include the private key in the device unless they have the devices call out to have a new certificate generated, perhaps 192-168-1-1.internaldevices.hp.net and so forth.
But now you are running TLS, so the address conflict would just yield a cert error. (If the other guy plugged his network or printer into yours, that is)
And at the same time, I've introduced an internet connection dependency and a 3rd party dependency. What happens when they decide to stop updating that cert, to save money?
I don't want all my internal network hosts exposed on a certificate transparency log.
I want my http connections to work without scary warnings in my local home network. Because if you show me scary warnings, and no meaningful way to implement the http connection securely, I will just start to ignore them. And if I ignore them in my lan, I will ignore them on the internet too. And that would be a net security loss.
So either use something else entirely inside a lan, like ToFU like ssh, or allow http connections without tls and without scary warnings. But I think deprecating http in local home lans with no meaningful way to make them secure is not a step in the right direction.
Harsh but true.
I don't have stats or data, but I don't think the households with devices that have web interfaces like a nas, routers, media centers, and stuff like this are small.
Personally I’d rather not.
I think the assumption is that for internal hosts you know the risks and can selectively ignore them but you should be warned about the issue on external hosts out of your control.
letsencrypt now supports wildcards, so that plus appropriate DNS setup should make it possible to use HTTPS on internal resources that you create so users other than you and other admins shouldn't need to worry. If you don't want to use an external resource for certificates then you could install your own CA key on the machines that connect to your network and then sign your own internal certificates though this is more work.
For things you really can't do much about, configuration pages for modems and routers for instance, your base users don't need to care, and you as an admin know the score.
I'm happy to have a little extra hassle as an admin so that the default for man-on-the-street users is as helpful as possible. We still need to properly educate people on exactly what "secure" means though, which is a grand task... "Don't put personal or login details into anything marked as not secure" is a starting point but that is a bit too simplistic as the transport being secure does not necessarily imply that the code at the other end is in any way trusted.
1. All your systems are provisioned to trust your CA, which can have any rules you like. This counts as "Secure". Almost certainly your rules are garbage, but I don't use your systems or trust your CA so I don't care
2. Your local systems which you refuse to be transparent about are marked "Not Secure" because there's no reason for a client to have any confidence in their identity
3. You offer transparency so that everyone (e.g. me) can see that there aren't any shenanigans with the global public systems we all trust.
The fact that you don't like any of these options doesn't mean there are no options, just that you didn't like them.
Because of time's arrow, it's mistake to assume that if you do nothing then nothing will happen, you're literally up against the Laws of Thermodynamics. The only people who think you might win that fight are crackpots building perpetual motion machines.
You might start a CA without transparency. Browsers would not include it by default, but at least you would only have to install it once and wouldn't have to run a CA yourself. (Or a CA service that would give everyone their own CA - I suppose these exist but there might not be a SOHO targeted one).
Or you could make a DNS zone provider that by default sets up a bunch of nondescript domain names with LE integration, so outsiders can't tell their purpouse or activity level from the CT log. This could also be sold to the router/printer vendors as the vendor-provided DNS, advertising that it's GDPR compliant.
Or put everything behind the same domain name, with different services using different ports.
But expanding that to the local LAN will promptly fall over as soon as captive proxies (which make remote sites look like they're in the local LAN) get involved.
Basically it comes down to eventually removing "secure" indicators completely and only indicating when a page is considered "not secure".
As an aside, Let's Encrypt has been a godsend to me during this change.
I think that's what made Google push this, since they are on the board of advisors for the Let's encrypt certificate authority.
JustHost, one of the hosts I have a few clients websites on for years, suddenly started to offer free Let's Encrypt SSL certs to protect users from this change (previously you had to pay for fixed IP, and the certificate itself) - what a great thing to happen.
All I had to do was change a few .htaccess files, a few DB entries and track down a few template files that had HTTP external JS references.
It was enough work that I had to invoice for the conversion (with the option of not bothering) - but annual fees are still the same, clients websites have SSL and every client wanted the upgrade, rather than be marked "insecure".
I really think this is a breakthrough change!
That's awesome :)
Now they are all asking to migrate, so it’s a good financial opportunity :)
(But to be honest, this is money that should have been earned during past years. Some of them are really stubborn)
I hope that flipping the switch now will cause enough of the remaining non-https sites to start looking into switching before Chrome feels the need to start adding "more prominent" warnings (for example using a modal dialog).
I agree that, yes, in general, we should all be using HTTPS on the internet, but non-secured HTTP still makes sense for example during development or for home routers and printers where traffic encryption is less important compared to the initial UX (my parents could probably set up a home router on their own if it's using non-encrypted HTTP but they would be totally unable to proceed if it's using a self-signed cert).
Chrome wants to move away from the "Secure" wording because people don't understand what it means, for example, they think it means they can trust the site not to misuse their credit card details.
Your information (for example, passwords and credit card numbers) is private when it is sent to this site.
To the layman this means: Chrome says it is safe to enter credentials on this site (and not that it just means that it is hard to eavesdrop on the connection), especially that because this does not say anything about the trustworthiness of the site.
I think this goes deeper. Currently, supporting HTTPS means you have to have some kind of internet connection, back-end infrastructure and other running costs.
Even if you use Let's Encrypt and DNS validation, you will have running costs to keep the domain name registered and you will need some way to periodically transfer new certificates to your devices.
Even if you somehow manage to update the device without a permanent internet connection, if someone wants to access the web interface, they will have to use the domain name - and therefore at least need to be connected to an internet DNS server so the domain resolves.
So if, at some point, browsers would completely drop support for HTTP, this would suddenly force any kind of device with a web interface into an IoT-style lifecycle where the device loses functionality once its vendor is not able to support it anymore - even if the vendor would want people to continue using the device and even if there is no technical reason for it.
For a $5 product it may not make sense to have this level of configuration, but for example I believe the FireBrick (a device you might buy to put a small company or district office online) is capable of being configured with your name rather than a generic product DNS name that could go away.
Also, just because a name is in DNS doesn't mean you must use the Internet to resolve the name. In a truly offline system you can just hard code that name resolution and it'll work fine. Nothing about HTTPS cares how resolution was actually done, only the BRs for the Certificate Authorities tell them they mustn't issue for names that aren't actually part of the public DNS hierarchy.
So, the device needn't be on the Internet.
The name must make sense in the Internet DNS hierarchy, but (with a typical commercial CA) needn't actually exist or (with Let's Encrypt, who insist on checking) needn't resolve to anything, let alone an actual machine on the Internet
Yes, you will need to move new certs to a device if you want it to remain publicly trusted as time passes. If that's an unacceptable burden (maybe your device is under the North Pole ice) then you probably didn't want the Web PKI, you need your own PKI for your very special application. Most people want the Web PKI.
However, my scenario was for situations where you don't want to modify the viewing device.
The advantages of web interfaces is that you get a complex GUI for your device without significant overhead on the device and without any requirements on the viewing machine. You can use an arbitrary PC or phone to access it.
If HTTP were to go, that would change: Either you restrict which machine can view the GUI (by requiring a specific resolver and/or CA) or you add the overhead of maintaining and updating the certificates and domains.
An example would be a (non-cloud) security camera or network printer. Those devices typically have a complex web interface for administration and data access - however, they are typically used within a LAN and there is no technical need why they need to access the internet. Indeed, when misconfigured, they can even be vulnerabilities.
As it is, the warning seems to be disabled for localhost/127.0.0.1 (where I only see a 'not secure' if I manually click the ⓘ) but the warning shows as usual if I browse a local IP address over plaintext HTTP.
To make it easier & cleaner in development, it's best to make yourself a Certificate Authority CA and issues local certificates. This makes for no warnings in browsers and ensures a better development experience.
A post from my colleague on how to do it https://reactpaths.com/how-to-get-https-working-in-localhost...
sure. That's what I do on those sites where I absolutely need SSL even during development. But it's still a hassle and, I would argue, an overall security downgrade.
If somehow that CA certificate gets out (commited to github by accident, extracted via malware, etc.), I become MitMable unless I manually check every certificate of every site I visit.
I know that this isn't too likely an attack vector, but if I had to target a developer friend, that's something I'd look into because this has the potential to work across machines whereas traditional malware based solutions would only work on machines I can compromise.
If you have unique CAs per development machine, this would of course be moot, but at that point, you might as well just run with a self-signed cert to begin with and allow the exception once.
A _Private Key_ is the thing that needs to be kept private, in Microsoft Windows it's common to bundle this together with a corresponding Certificate in a single file, often with the filename extension .PFX I assume it's more "convenient" this way, shame about the security.
If you do this a LOT (maybe you're a team of fifty developers at a software company that mostly builds web apps but has a strict policy of not using "real" certificates or wildcards) you should mimic the hierarchy required of "real" public Certificate Authorities:
Mint a "root CA". You'll end up with a certificate and a private key, let's call them root-C and root-P. Every developer (and QA and so on) system needs to trust root-C, you can use Group Policy or similar tools to arrange that.
Use the root CA to issue a sub-CA, the "issuing CA". Write _constraints_ in the certificate used to issue this sub-CA. A constraint is a rule about what things the Subject is an authority about in the opinion of the Issuer. So for example if you set a DNS constraint of just example.com, certs for example.org, or google.com from this Issuing CA don't work. If you later acquire example.org, you can "just" replace the Issuing CA. No updates to employee systems. Think about the Constraints you write, so that they block "mistakes" like MITMing google.com, but not anything you expect to actually need. You can also constrain the types of certs issued. Will you only issue TLS server certs? Then write a constraint saying so.
Now, lock away root-P, a serious CA has it in a special hardware device to protect it, but a USB key in a locked desk drawer is a good first step.
The Issuing CA credentials will probably need to stay live on someone's computer, they're valuable of course, but because of the Constraints they now aren't an unlimited black hole in your security.
But are you telling me that each developer should do this for their personal webpage project just because Chrome might decide to put HTTP-only pages behind a modal dialog?
If you're a bit bigger, so that you're needing to put webpage projects on a separate machine, so maybe QA can try it, or you can run a demo, you can and should set aside one or more chunks of public DNS hierarchy for the test systems, for example a cert for *.test.example.com can allow a number of test systems at Example Inc to do HTTPS. If you're happy to pay a commercial CA they'll mint such a certificate for fair price upon proof you control example.com. If you want to use Let's Encrypt, they'll need you to have records for test.example.com in public DNS to run proof of control automatically. Provisioning the private key and copies of (periodically updated) certificates to the test boxes is not exactly a difficult problem for a working test environment.
Only if you (perhaps out of paranoia) refuse to do that, should you try what I suggested with a private CA hierarchy for web pages.
If you're building something quite different (not TLS, or genuinely not on the Internet, although what the point of things other than the Internet is I'm not sure) then you can and should roll your own PKI, but that's a huge under-taking, you should already have hired at least one person who knows MORE about this than me or you're already in deep trouble.
- create an "internal" domain for your lan, e.g. home.example.com
- make AWS Route53 handle that zone
- create some AWS IAM credentials for Route53
- create some hosts (e.g. router.home.example.com)
- use certbot with the route53 dns option to get a certificate and private key. Certbot will automagically add some TXT records to verify hostname ownership and provide you with that.
NO NEED to expose anything on your public IPs, but mind you: your hostname will appear in public CT logs. No "greatnascontainingmypartnersnudephotos.home.example.com" hostnames!
As long as http still works it’s fine, I think a security warning about it is probably a good thing, but there definitely are places where “just use let’s encrypt” isn’t an acceptable solution.
Edit: was doing some reading and found this interesting post: https://vpnpick.com/chinas-wosign-ca-found-threaten-users-le...
2. I'm beginning to see the HTTPS thing as some kind of strategic war move on the part of the US, possibly 5 eyes, possibly other countries. I don't see it making things simpler, only more complicated (one example I can give is https://news.ycombinator.com/item?id=17540111 - it's a lot harder for me to analyze Web traffic within my own LAN now, I have to set up a machine capable of breaking HTTPS, then secure it well enough I'm still confident to do my banking/etc).
> [$500][394518] Medium CVE-2018-6169: Permissions bypass in extension installation . Reported by Sam P on 2014-07-16
And given the relatively low issue number (e.g. http://crbug.com/394520 is from 2014), it's not a typo.
O.o
This change has the effect of pushing even mundane websites to use SSL, and so locking out corporate-level and other players from analysing web usage, or at least making them less effective, which enhances and increases the Google's "web scale" analysis dominant position even more.
This data can provide a fair bit of powerful insight and intelligence into things like change of trends and growth of businesses.
In order to analyze my own information/data, I have to break HTTPS (setup a proxy MITM box, install CAs on all devices), then put it back together again securely enough (secure++ the MITM box) to be confident in doing my banking etc.
Argh.
That sounds a lot like wiretapping to me. How did this not already fall under wiretapping laws?
Here's a link to hn.algolia.com for the search 'ssl revoked.'
https://hn.algolia.com/?utm_source=opensearch&utm_medium=sea...
What happened to "do no evil". Seems to be all google do now.
I've heard this nonsense over and over again, and not a single person has been able to provide a plausible explanation why this is a bad thing to do.
Personally don't understand the heavy push to force https on everything and anything. The maintenance/time required to set up and maintain is not insignificant and is really quite pointless in many situations. Do you really need an encrypted connection to LOLCats?
If you only use an encrypted connection when you need it, then one can know that, well, you need it.
You have nothing to hide... until you do.
These sites will continue to be entirely accessible, so I have no idea what solution you think is required. If a provider wants to upgrade such that their site is no longer insecure, then they can pay to upgrade it themselves.