Progress Towards 100% HTTPS, June 2016
letsencrypt.org
letsencrypt.org
Plex did solve this in conjunction with a certificate authority, but that solution only works for them. The general approach could work for others if someone like letsencrypt led the effort. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
And before you tell me to set up my own local authority and add it to the chain on every device ... common, really? Nobody wants to do that.
Compare with SSH, which prompts to save the fingerprint on first connect, and warns loudly if the fingerprint changes. This is a superior way to handle self-signed certificates.
The Plex approach would be possible with Let's Encrypt, though you would have to find a way to avoid running into rate limits (via PSL or by making users use their own domains, which is admittedly only an argument if you're catering to a technical audience).
[1]: https://cabforum.org/wp-content/uploads/Guidance-Deprecated-...
You'd need a way to get past the rate limits (either via PSL or with a rate limit exception), but other than that this is doable.
Nothing would stop someone from getting a certificate for the hostname "myfridge" on their LAN, then going to your LAN and using the same one to perform MitM for your "myfridge".
The plex approach is very interesting though! There would be a lot to think out, but LetsEncrypt could do it if anyone could.
Which brings up an important point that is often lost amongst the "encrypt everything!" "hype" prevalent today: you should be able to MITM the traffic of every device you own, or else you do not really own them and cannot tell what information they are actually communicating. Keep in mind that incidents like the smart TVs spying ( http://arstechnica.com/security/2013/11/smart-tv-from-lg-pho... ) were easily noticed because the data was in plaintext.
When pushing for more security, I think it is extremely important to be aware of all the consequences and pause to think deeply before we end up locking ourselves out of things we own, because by the time we realise, it will be too late.
The problem is not encryption... the problem is buying black box devices which are not transparent to their users. Bad manufacturers will always be able to do this whether we advocate for encryption everywhere or not.
If someone like letsencrypt helped solve the issue (probably in a manner substantially similar to plex) then the devices will be able to get and renew their own certificates automatically, and clients talking to them would just work.
There's no CA to tell you that it's a valid cert for this specific location. But you're the owner and you're the authority in this case.
If you were a device manufacturer what would you do? One approach is to make all communication happen with "the cloud" as an intermediary, but that means that local operation is dependent on the Internet and some backend running on it somewhere. Or you have to come up with some hack, confusing instructions for users, lots of documentation etc. We see the results in Matthew Garrett's most recent post, and it isn't pretty.
What I'd do as a dev manufacturer? I'd try to change the game entirely. The current system simply did not have devices like that in mind. One idea would be "device certificates" - basically known CAs that can certify MAC addresses. This should be enough for local networks.
Amusingly mac addresses aren't as constant as you'd think. On my home lan I use a netgear wifi range extender. The way it works is to give fake (transformed) mac addresses for devices connected to it. For example if the real mac address is 11:22:33:44:55:66 when connected to the main access point, then when connected to the wifi range extender the rest of the network will see the mac address as aa:bb:cc:44:55:66. (The range extender also has ethernet ports - this affects wired and wireless connections to it.)
But that's all we've got. Unless we start integrating some kind of factory-sealed guaranteed-unique identity chips in all devices, there's simply no work around. Once something is on your network, you manage the identities. Either you have to manage some kind of CA, or trust whatever the factory provided you.
I think this can be solved the same way plex did, by combining separate DNS space with a certificate authority issuing certs programmatically like letsencrypt does.
Connectivity [1] and using a global namespace are orthogonal things: you can use global DNS namespace just fine independent of connectivity. So from the naming perspective it Just Works if you get certs for printer.yourhouse.you.tld and fridge.yourhouse.you.tld.
(Of course you'd still like an automated cert renewal system for this disconnected case, but that's just a "simple matter of programming".)
[1] assuming by "LAN" you meant "network disconnected from the Internet"
How effective is something like certificate pinning against fraudulent certs?
Er, by whom?
Morally wrong, sure, but you know, politicians and law enforcement...
My personal opinion on the "nation-state adversary forces CA to misissue" topic boils down to this: It's unsuitable for mass surveillance as it's easy to detect. It would work for targeted attacks, but in all likelihood your adversary will use other means to get in (zero-days, someone on the inside, physical compromise, etc.). Even for a targeted attack, my guess is that these other means would be less likely to be detected and would be significantly cheaper (if you take into account the cost of causing a root CA to get removed).
There are a lot of ideas for catching this and some of them are starting to work, like HPKP pinning and preloads, and in the long run Certificate Transparency (including not accepting certs that haven't been publicly disclosed).
If you use HTTPS Everywhere, you have an option to submit certs that you see to the EFF SSL Observatory.
I don't mean to minimize the threat; I think there are lots of sites and browsers against which misissued certs can still be successfully used today without detection, and it's important to keep working on making that no longer true.
Certificate Transparency would also help here, as it would allow site owners to monitor the logs for any certificates they did not request. This is more about detection as opposed to prevention (though the chilling effect of easier detection would help with prevention, I suppose). Admittedly, this is probably something only a couple of large, security-conscious organizations do (like, for example, Facebook, which detected that someone was issuing certificates against internal policy, though not maliciously in that case).
If the bogus certs are not logged in Certificate Transparency, they will be rejected by Chrome: https://security.googleblog.com/2015/10/sustaining-digital-c...
If they are logged in Certificate Transparency, then the world will know, the offending certificates will be immediately blacklisted, and Symantec will be booted from root programs.
With the ongoing advancements in Certificate Transparency, your faith in the Internet PKI should be growing, not waning.
> However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.
So finding questionable certificates is trivially easy, but nobody ever bothers to look? What good is that?
As for everyone else, give it some time. The ecosystem is still very young and we're still developing tooling.
Are there any end-user tools? When I open twitter.com, I would love for my browser (or my phone if I'm using an app) to tell me that the certificate fingerprint has changed unexpectedly since the last time I visited.
https://addons.mozilla.org/en-US/firefox/addon/certificate-p...
Why are all these tamper detection tools targeted to domain owners rather than end users?
I was thinking about this because I was wondering if you could use secure dns to store certificate fingerprints. That doesn't make sense though because secure dns also depends on PKI.
Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in the user's minds.
That's the point. Having some authority who did at least some minimal checking, to extensive checking, and who will verify you really are who you purport to be. Trust but verify probably plays a part in this.
But, remember, you don't have to go to HTTPS. There is no requirement for you to do so.
Cert companies only do a phone call check for the very expensive EV certs. There is no minimal to extensive checking. That is a scam.
Web tech is all https now. I can't even browse a lot of https sites with some of my older devices. There is a requirement and I dislike it.
What if a customer who trusts you returns to your site, but ends up on an impostor's site instead? He was no way to discern the difference.
Actually I called shutterfly.com on the phone about that mixed content issue. I emailed them screenshots of the error from 6 different operating system and browser combinations, from 3 other users even. They claimed nothing was wrong. They were serving javascript via http on an https page and told me I was wrong and needed to update java, for weeks, on the phone, in chat, and in email, and declined to send the report to their webmaster. Even those wanting to be trusted are incapable of using these tools, from what I have seen. The whole thing is broken.
You generally have to modify the root domain to host a random value in a text file the cert company gives you. This demonstrates that you have control of the domain.
Aka, minimal checking.
Granted, that doesn't prove that you're the domain owner, but if you aren't the domain owner and you've got enough access to pass that challenge, the real own has security problems a cert isn't going to fix so hey.
All things considered, it's a hell of a lot better than nothing.
What devices do you have that don't support TLS?
Also, the point is not to trust you or not, it's to trust that I'm actually talking to you and not a MitM.
That does not mean that you know something about Security.
> ... why should we trust you?
That's exactly the point. This is INTERNET, we don't trust anyone, it's a dangerous place to do such action... but we have to, otherwise it's better to go a live up in the mountain.
So, I prefer to trust Symantec/Google/DigiCert/etc... instead of some small business that does not even know the meaning of updating software or change default passwords.
The chain of trust it's a burden, I know, why we should trust anyone? But there has to be some level of trust between two parties, and, if we can have a third one (Like an escrow) that can ensure that trust I think it's great. Even using asymmetric encryption you need to trust the other party's public key...
A quick example of an unencrypted, cert-less network, an unsecure one with tons of vulnerabilities is the SS7 and the GPS systems... Since they cannot add Certificates to their BTS (base transceiver station) or their satellites, because of roaming technology, it's quite easy to set up an antenna an spoof them[1] and have full control over you phone and GPS[2]
[1] https://julianoliver.com/output/log_2014-02-13_17-17
[2] http://permalink.lanl.gov/object/tr?what=info:lanl-repo/lare...
That said, I am actually trying to move to a rather isolated place, and that is a perfectly valid option, so don't knock it.
That's what HPKP does, basically, unless I'm misinterpreting what you mean with service providers.
HPKP is Trust on First Use, so it's not perfect, but the alternative - some kind of Web of Trust - is not really practical for non-technical, not-security-conscious users, IMO.
Sadly I understand https much better than alternatives, due to web hosting experience. I am trying to catch up.
Meanwhile at work we're juggling dozens of certs left and right each with their own expiry as a handout to CAs. There's no reason why CAs cant sell me a cert that has a decade expiry. If the cryptography it uses goes bad, we'll just replace it. Why am I constantly buying these things?
Everything about CAs and browsers are wrong. Especially when many browsers ship with root certs from entities controlled by autocratic governments with zero accountability and involved in cybercrime and cyberspying. I'm giving incredible access to these nation states by downloading Firefox, Chrome, or IE. How is this "secure" again?
Were the certificate to contain an IP address (or IP addresses), it would need to be updated every time the site started or stopped using a public-facing IP address.
I share your frustration and I understand that trying manage levels of trust a tough problem compounded by the fact that a user's expectations are fluid.
The chain of trust is not to tell your users to trust you. It's to tell your users not to trust me, even if I look just like you.
How can you cover 7 million unique domains if you've only issued 5 million certificates?
LetsEncrypt is almost built upon the idea of frequently (and automatically) re-issuing your certificate(s). The graph's line shows what appears to be an accumulated sum of certificates issued by day.
If every 90 days most certificate(s) expire, of course the graph will look like that!
Whats most interesting to me is the steps up in the graph. It appears that the steps in the graph roughly occur on 70-90 day intervals.
Impressive growth for a great mission/service, but I wanted to point out the mechanics behind the graph. Hopefully others can offer some alternative perspectives!
edit: Grammar, illogical sentence structure.
https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
Though, it would be nice if the likes of dyndns names were given exception, since they are effectively second level tld's.
https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns...
But unfortunately it doesn't seem like Let's Encrypt currently has any plans to add wildcard certs any time soon.
Generally, if you're relying on your internal hostnames being secret (which is a terrible idea anyway), you should consider using an internal CA, because there's a good chance all public CAs will start logging every single certificate they issue to public logs, and that would include all the domains the certificate is valid for¹. Better yet, don't treat your hostnames as secrets.
¹ I think there has been some discussions about allowing CAs to censor DNS labels after the TLD+1 level for Certificate Transparency. Not sure if that's going to happen, I'm not a fan. This would still require that your CA supports this mechanism, something I don't think Let's Encrypt would do.
Remember, once you encrypt a web resource in SSL, you add a ton of baggage on top of any methods that might be used to access it.
I like a world in which I can 'nc' a web resource and manipulate it with unix primitives without a truckload of software dependencies.
If sensitive information is involved, then certainly - use SSL. I understand that we must give up conveniences for that functionality.
But there are a lot of web resources that have existed, do exist, and potentially exist that are completely benign ... I think we're shackling ourselves by chasing after this perfection.
Or, put another way, we're chaining ourselves to a world where web resources are only accessed by web browsers, and only by those web browsers that are chaining themselves to a fairly dubious security scheme...
I do fully agree that the web is getting more tied to browsers, and to me that's worrying, but TLS is mostly a transparent tunnel over which you can use the same protocols; it's not part of that trend, in my opinion.
That way when https is found to lack some feature, we can easily upgrade to httpz almost immediately?
The http in https just means http. It has evolved from http/1.0 to http/1.1 to http/2.
I'm not sure what you're asking or how it is relevant to Let's Encrypt.
The "s" in HTTPS is for "secure", and TLS provides that security.
TLS is a evolving standard which is updated over time to add new features when necessary. When HTTPS is negotiated, it can seamlessly choose which version of TLS to use, based off what the client and server want to use.
So, HTTPS will never die due to lack of features. A new version of TLS will just be approved and deployed, and newer devices can use that while older devices can get by on an older version of TLS.
TLS is the successor to SSL. They are backwards compatible, so devices that support TLS also support SSL. The full version history, from newest to oldest, is: TLS 1.2, TLS 1.1, TLS 1.0, SSL 3, SSL 2. In reality, very few servers still use SSL 3 or SSL 2, due to known weaknesses, but colloquially, all the versions are just called "SSL".
TLS 1.3 is underway and will shortly be ready for primetime. Firefox and Cloudflare have already written some implementations based on the draft spec (sorta how routers will implemented the newest 802.11 standards before they are 100% official).
Encrypting everything increases the demand for low-rent SSL certs. Anything below OV (Organization Validated) is junk, and if money is involved, an EV (Extended Validation) cert should be used. Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.
Adding SSL makes it a lot more complex and limits your toolset dramatically.
If your source is sensitive, by all means - use SSL. I don't think anyone would argue with that.
But if you provide a useful resource that isn't sensitive or controversial (say, for instance, the weather) why would you want to chop off so much interoperability ?
I guess if the only way you've every used the web is with a web browser, this doesn't make any sense to you.
The goal behind the HTTPS everywhere effort isn't just to encrypt private data, but also to provide authentication for your content. ISPs are known to interfere with HTTP requests, injecting ads, malware and what not. That's something that affects anyone, even static sites.
Many people, including you, forget that TLS protects content from tampering. ISPs, captive portals, and other network entities are known for injecting ads or intercepting transmissions. Imagine your liability if a bad actor is injecting child porn on your site to a large portion of your audience. This isn't unheard of, by the way. Arguably less criminal, even Comcast is known for injecting content into pages.[1]
Some really cool HTML and JS functionality will only work over HTTPS.
> Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length.
If you have an attacker than can identify content solely from its length, you have bigger problems than an SSL cert can solve.
> Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.
I do not see the problem. All those domain owners consciously choose to have Cloudflare host their stuff. The cert might be a few KB bigger, but who cares?
Some really cool HTML and JS functionality will only work over HTTPS.
What "really cool" HTML feature requires HTTPS? There can be problems with mixed secure/insecure content, but that's more of an offsite content issue.
> Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length.
If you have an attacker than can identify content solely from its length, you have bigger problems than an SSL cert can solve.
An eavesdropper knows the IP address and the length of the content, even if it's encrypted.
> Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.
I do not see the problem. All those domain owners consciously choose to have Cloudflare host their stuff. The cert might be a few KB bigger, but who cares?
When sites share an SSL cert, and you can break into one of the sharing sites, there's a way to impersonate others. Cloudflare customers for their lower tiers of "security" often don't realize this. The customer doesn't pick which sites share certs; that's up to Cloudflare.[1]
[1] http://john-nagle.github.io/certscan/whoamitalkingto04.pdf
One example would be the the Geolocation API, with more to come[1]. Another example (specifically for HTML) would be Mozilla showing a user-visible warning when it encounters a type="password" field in a form served via HTTP (or with a HTTP target - I'm not certain). This is currently only enabled in the Developer Edition, but will eventually land in stable.
> When sites share an SSL cert, and you can break into one of the sharing sites, there's a way to impersonate others. Cloudflare customers for their lower tiers of "security" often don't realize this. The customer doesn't pick which sites share certs; that's up to Cloudflare.
This is a non-issue for services such as CloudFlare. Site owners do not have access to the private key, only CloudFlare does. Breaking into one of the other sites won't give you access to the private key, only breaking into CloudFlare would, and such a vulnerability would have nothing to do with the fact that you're sharing a SAN certificate with other sites. I'm not aware of any other cross-site vulnerabilities that stem from shared certificates in an environment where every site on that certificate is served by the same frontend.
[1]: https://www.chromium.org/Home/chromium-security/deprecating-...
Ugh. Why would they do that ?
I can understand that geolocation could be tremendously sensitive and you absolutely would want to offer the option of SSL ... but why limit it to SSL ?
geolocation is also something that you'd want to hack into and build into things ... and maybe even things with limited processing power and memory.
Wouldn't it be nice to have the option to interact with a geolocation API (over http) with stdio and not include a giant truckload of dependencies and libraries and megabytes of packages ?
I think you answered your own question. ;-)
> geolocation is also something that you'd want to hack into and build into things ... and maybe even things with limited processing power and memory.
Presumably, once your device is capable of running a modern browser such as Chrome or Firefox (which is what we're talking about here), TLS is a drop in the bucket in terms of resource usage. Or were you talking about the server?