Supporting Let’s Encrypt, the nonprofit making HTTPS free for all(blog.1password.com)
blog.1password.com
Supporting Let’s Encrypt, the nonprofit making HTTPS free for all
https://blog.1password.com/supporting-lets-encrypt/
91 comments
The intuitive properties you expect from HTTP actually aren't delivered and can't be delivered, except over HTTPS.
A lot of people focus on the confidentiality element of TLS. "Clearly I don't need for it to be secret that I looked at the Wikipedia entry for Napoleon (the 1995 movie, not the famous guy)".
But TLS bundles together three things and if you need any of them you can't have them with plain HTTP. You get confidentiality, but you also get integrity and authentication.
That means when you curl https://foo.example/something we can promise you that the result is the resource https://foo.example/something - maybe that's not what you actually wanted, maybe it's full of lies or worse, but it is what you asked for and it is what you get. With plain HTTP all bets are off, anybody can interpose and present anything else to you.
If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? You could make up whatever you want, it's a black-and-white movie about a dog who ruled France and then went into space, and it was the #1 grossing movie in every country for six years.
A lot of people focus on the confidentiality element of TLS. "Clearly I don't need for it to be secret that I looked at the Wikipedia entry for Napoleon (the 1995 movie, not the famous guy)".
But TLS bundles together three things and if you need any of them you can't have them with plain HTTP. You get confidentiality, but you also get integrity and authentication.
That means when you curl https://foo.example/something we can promise you that the result is the resource https://foo.example/something - maybe that's not what you actually wanted, maybe it's full of lies or worse, but it is what you asked for and it is what you get. With plain HTTP all bets are off, anybody can interpose and present anything else to you.
If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? You could make up whatever you want, it's a black-and-white movie about a dog who ruled France and then went into space, and it was the #1 grossing movie in every country for six years.
> If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all?
This is probably the argument I hear most often. But it completely ignores the fact that for the last 20 years, when I wanted to grab a Wikipedia article, I got it in 100% cases, whereas the number of broken HTTPS websites (usually because of expired certs) is non-negligible. You can blame "incompetent admins" as much as you want, but with HTTP this particular problem simply doesn't exist.
This is probably the argument I hear most often. But it completely ignores the fact that for the last 20 years, when I wanted to grab a Wikipedia article, I got it in 100% cases, whereas the number of broken HTTPS websites (usually because of expired certs) is non-negligible. You can blame "incompetent admins" as much as you want, but with HTTP this particular problem simply doesn't exist.
Sure, it is incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. But regular users want WiFi at their favorite coffee shop, and there are still plenty of unsecured wireless hotspots at those shops. The capability to intercept insecure WiFi has been heavily commoditized over the years since the techniques were created. Well within reach for a disgruntled lover, or a stalker, or perhaps for corporate espionage. Sure, more sophisticated organizations should have and more often do have protections for this (including, of course, strong TLS/HTTPS) but not everyone does, and we should protect them too.
But that's just in the US, what about in countries where the ISP is far less than trustworthy. It's feasible that a state actor or other malicious actor could replace your web page with a phishing page. A non-sophisticated user (or even a somewhat sophisticated one, if the phishing attack is done well enough) might make that critical mistake that grants access to what is normally highly secured, but because a webmaster who doesn't understand the risks decided not to enable HTTPS, the user's personal information (or worse, their life) could be at risk.
But that's just in the US, what about in countries where the ISP is far less than trustworthy. It's feasible that a state actor or other malicious actor could replace your web page with a phishing page. A non-sophisticated user (or even a somewhat sophisticated one, if the phishing attack is done well enough) might make that critical mistake that grants access to what is normally highly secured, but because a webmaster who doesn't understand the risks decided not to enable HTTPS, the user's personal information (or worse, their life) could be at risk.
> incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US.
Comcast and other ISP's would love to have a word with you with their injecting JavaScript to warn you about going over your alloted data usage... same for various other providers that injected ads, or man in the middled YouTube connections (T-Mobile) to reduce the quality delivered over their network or the hidden CDN's to reduce interconnect load...
ISP's have "managed" their networks in a variety of ways, and a lot of those "techniques" were straight up hijacking your original request.
Comcast and other ISP's would love to have a word with you with their injecting JavaScript to warn you about going over your alloted data usage... same for various other providers that injected ads, or man in the middled YouTube connections (T-Mobile) to reduce the quality delivered over their network or the hidden CDN's to reduce interconnect load...
ISP's have "managed" their networks in a variety of ways, and a lot of those "techniques" were straight up hijacking your original request.
T-Mobile is throttling all traffic from certain IP addresses in their current Binge On scheme, primarily to reduce edge load (on their cell towers) as that is where nearly all of their network congestion occurs.
Binge On doesn't do much different for http video content compared to https content as far as I have read and seen.
Binge On doesn't do much different for http video content compared to https content as far as I have read and seen.
These days they may simply throttle entire IP blocks, there was a time when they would purposefully change the manifest file that was served to users to reduce the available qualities thereby forcing the client to think there was no higher quality video content available.
A state actor can issue a certificate, because the browser's default cert stores are full of sketchy ones.
The Internet didn't exactly collapse between 1990-2010, before this HTTPS-everywhere campaign started.
Interest groups want to get you hooked on HTTPS and then squeeze you, one way or another.
The Internet didn't exactly collapse between 1990-2010, before this HTTPS-everywhere campaign started.
Interest groups want to get you hooked on HTTPS and then squeeze you, one way or another.
No, it doesn't work like that. Certificate Transparency Log makes this almost impossible to do this undetected.
In addition to this you have CAA records which quickly would make it evident for the entire world that said certificate is fraudulent and that the signing CA isn't to be trusted anymore.
In addition to this you have CAA records which quickly would make it evident for the entire world that said certificate is fraudulent and that the signing CA isn't to be trusted anymore.
I used to think that CAA records would be checked at both issuance time and certificate acceptance time, but someone on Hacker News (probably tialaramex) corrected me: the CAA RFC specifically says that it should only be checked at issuance time and that it's not valid to check it at acceptance time. As a result, there's no browser that checks CAA or uses it to warn about possibly-misissued certificates. Furthermore, if you reported a certificate to a CA or browser based on an apparent conflict with CAA issuance policies, you would probably get the reply that that only applies at issuance time.
And someone in possession of a misissued certificate that was being used for an attack might try to take care not to present it to researchers doing Internet-wide scans (at least to avoid attracting even more attention). But nowadays it would have to be logged in CT logs, so researchers could find it if they had some reason to suspect it -- or, hopefully, the legitimate site operator could find it.
Conclusion: CAA (by design) typically only protects you from accidents; it doesn't really help to prevent or detect deliberate misissuance. But CT does.
And someone in possession of a misissued certificate that was being used for an attack might try to take care not to present it to researchers doing Internet-wide scans (at least to avoid attracting even more attention). But nowadays it would have to be logged in CT logs, so researchers could find it if they had some reason to suspect it -- or, hopefully, the legitimate site operator could find it.
Conclusion: CAA (by design) typically only protects you from accidents; it doesn't really help to prevent or detect deliberate misissuance. But CT does.
Makes complete sense, and like you said, this information is key for security researchers who routinely trawls CT logs looking for discrepancy. And failing on CAA shortly after issuance is quite a huge red flag. If the scenario of rogue national state managed CAs was an issue we'd have pretty good evidence of it by now.
Another, somewhat unrelated, benefit of CAA records is that it allows you to keep tighter control over who and what inside your organization is allowed to issue/control certificates.
Another, somewhat unrelated, benefit of CAA records is that it allows you to keep tighter control over who and what inside your organization is allowed to issue/control certificates.
Yes, it probably was me.
CAA assumes the Certificate Authorities are honest which I believe on the whole is a reasonable assumption - but it doesn't only protect you against accidents. Malevolence from third parties might be blocked by CAA too.
For example, suppose you conclude the some of the 3.2.2.4 Blessed Methods are unacceptably vulnerable to impersonation of your organisation. You identify that a particular CA specifies in their CPS that they never use any of these methods, you can use CAA to tell every other CA not to issue. As a result, these methods cannot be used to successfully obtain certificates that shouldn't exist. If an adversary tries to use another CA your CAA record tips off that CA that there's a problem, and if they try on your preferred CA then the vulnerable methods aren't offered.
I believe there is still work in progress to try to hook CAA together with ACME so that it would be practical to express "Only Let's Encrypt may issue, and only using dns-01" which rules out a lot of otherwise practical attacks for a resourceful adversary, but I don't track the status of that work.
CAA assumes the Certificate Authorities are honest which I believe on the whole is a reasonable assumption - but it doesn't only protect you against accidents. Malevolence from third parties might be blocked by CAA too.
For example, suppose you conclude the some of the 3.2.2.4 Blessed Methods are unacceptably vulnerable to impersonation of your organisation. You identify that a particular CA specifies in their CPS that they never use any of these methods, you can use CAA to tell every other CA not to issue. As a result, these methods cannot be used to successfully obtain certificates that shouldn't exist. If an adversary tries to use another CA your CAA record tips off that CA that there's a problem, and if they try on your preferred CA then the vulnerable methods aren't offered.
I believe there is still work in progress to try to hook CAA together with ACME so that it would be practical to express "Only Let's Encrypt may issue, and only using dns-01" which rules out a lot of otherwise practical attacks for a resourceful adversary, but I don't track the status of that work.
I fully agree with the theoretical threat vector.
But is it an actual, practical, meaningful threat vector or an issue for the type of website I describe (empathically, NOT top 20 site, like Wikipedia is:)?
Everything in IT and IT Security is or should be an evaluation, a compromise of specific graphs of price and effort and impact and risk. My question is not "Should Wikipedia have HTTPS", but "Does every single one of remaining 15% of websites need to be encrypted", and that's not a persuasive argument.
But is it an actual, practical, meaningful threat vector or an issue for the type of website I describe (empathically, NOT top 20 site, like Wikipedia is:)?
Everything in IT and IT Security is or should be an evaluation, a compromise of specific graphs of price and effort and impact and risk. My question is not "Should Wikipedia have HTTPS", but "Does every single one of remaining 15% of websites need to be encrypted", and that's not a persuasive argument.
> But is it an actual, practical, meaningful threat vector or an issue
Back when http was common and 3G was still kinda expensive, many public WiFi networks would MITM all the web pages you request to inject their own ads into them.
A notable example I remember vividly - the public WiFi network of Moscow Metro used to do this for non-paying customers, and it was particularly bad because 3G/4G did not work well underground back then.
This alone was a good motivation to switch my plain-html ad-free websites to https as soon as Let's Encrypt became a thing.
Back when http was common and 3G was still kinda expensive, many public WiFi networks would MITM all the web pages you request to inject their own ads into them.
A notable example I remember vividly - the public WiFi network of Moscow Metro used to do this for non-paying customers, and it was particularly bad because 3G/4G did not work well underground back then.
This alone was a good motivation to switch my plain-html ad-free websites to https as soon as Let's Encrypt became a thing.
Vive le roi chien de l'espace!
A fair question deserving a real answer, rather than downvotes.
1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities.
2. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad.
3. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though.
4. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [1]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [2].
5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons:
* Reduced admin overhead not having to bother with certs
* It enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3]
* Better support for very old devices, such as old smartphones in the developing world
[0] https://doesmysiteneedhttps.com/
[1] https://www.theguardian.com/us-news/2016/jan/13/us-library-r...
[2] https://arstechnica.com/information-technology/2015/04/it-wa...
[3] https://web.archive.org/web/20200615045650/http://whydoesapt...
(Based on an old comment of mine at https://news.ycombinator.com/item?id=22147858 )
1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities.
2. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad.
3. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though.
4. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [1]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [2].
5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons:
* Reduced admin overhead not having to bother with certs
* It enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3]
* Better support for very old devices, such as old smartphones in the developing world
[0] https://doesmysiteneedhttps.com/
[1] https://www.theguardian.com/us-news/2016/jan/13/us-library-r...
[2] https://arstechnica.com/information-technology/2015/04/it-wa...
[3] https://web.archive.org/web/20200615045650/http://whydoesapt...
(Based on an old comment of mine at https://news.ycombinator.com/item?id=22147858 )
I feel the notion of "I don't want to deal with HTTPS" is mostly to blame on the ridiculous UX of cert management in the past. The act of creating a CSR alone using openssl is reason enough to justify the emotional rejection of HTTPS.
Since I switched all my setups to Caddy [1] using HTTPS by default has become an absolute no-brainer and nothing to care about, as it simply happens automatically due to its built-in ACME support.
[1] https://caddyserver.com/
Since I switched all my setups to Caddy [1] using HTTPS by default has become an absolute no-brainer and nothing to care about, as it simply happens automatically due to its built-in ACME support.
[1] https://caddyserver.com/
> 1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities.
1a. Spy agencies or botnets that have compromised routers and want to attack Internet users. (The spy agencies are probably more of a concern for backbone routers, while the botnets are probably more of a concern for CPE routers.)
> 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons:
I've encountered, I guess, five others: you want to use the server in a mostly or totally offline environment (so it can't count on getting Internet access to perform renewals), you want to use a totally air-gapped environment, you don't possess a domain name or can't be sure of renewing it for some reason, you want to use web protocols for a very lightweight (but not necessarily very old) embedded system in a LAN, or you are subject to sanctions that prevent CAs from charging you for a certificate and/or issuing one to you at all.
I guess also "for some reason you want to use TCP/IP on a point-to-point link to collect telemetry where very low latency is your absolute highest priority, and integrity and/or confidentiality are handled sufficiently by some other layer somehow". (Although in that case the client probably isn't a web browser, so this probably isn't an issue.)
1a. Spy agencies or botnets that have compromised routers and want to attack Internet users. (The spy agencies are probably more of a concern for backbone routers, while the botnets are probably more of a concern for CPE routers.)
> 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons:
I've encountered, I guess, five others: you want to use the server in a mostly or totally offline environment (so it can't count on getting Internet access to perform renewals), you want to use a totally air-gapped environment, you don't possess a domain name or can't be sure of renewing it for some reason, you want to use web protocols for a very lightweight (but not necessarily very old) embedded system in a LAN, or you are subject to sanctions that prevent CAs from charging you for a certificate and/or issuing one to you at all.
I guess also "for some reason you want to use TCP/IP on a point-to-point link to collect telemetry where very low latency is your absolute highest priority, and integrity and/or confidentiality are handled sufficiently by some other layer somehow". (Although in that case the client probably isn't a web browser, so this probably isn't an issue.)
This is a good comment. There are I believe a couple more cases where HTTPS is difficult:
- You use a dynamic subsubdomain scheme. E.g. abc.xyz.example.org. A wildcard certificate for *.example.org only covers xyz.example.org, not abc.xyz.example.org. Requesting a certificate as the page is requested is possible, but will cause a lot of latency, and you will probably hit the Let's Encrypt rate limit;
- You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons;
- You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network.
These cases are not that common, but that does not make them nonexistent. 99% of websites don't fall under one of these cases (there are probably some others I have not even considered), and should probably support HTTPS.
These cases are not that common, but that does not make them nonexistent. 99% of websites don't fall under one of these cases (there are probably some others I have not even considered), and should probably support HTTPS.
I see HackerNews chewed up your formatting. An extra newline between bullet-points is necessary.
> You use a dynamic subsubdomain scheme
Good point. If you run a site that creates a new subdomain per customer, and uses subsubdomains, you might end up making a high volume of cert requests. I don't know a lot about this stuff but presumably there are paid CAs that offer a more generous rate limit than Let's Encrypt?
> You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons
When is this a problem?
> You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network
I don't follow here. If for some reason you need to present that data as a local HTTP service, that service could just act as a proxy to GitLab Pages over HTTPS, no?
> You use a dynamic subsubdomain scheme
Good point. If you run a site that creates a new subdomain per customer, and uses subsubdomains, you might end up making a high volume of cert requests. I don't know a lot about this stuff but presumably there are paid CAs that offer a more generous rate limit than Let's Encrypt?
> You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons
When is this a problem?
> You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network
I don't follow here. If for some reason you need to present that data as a local HTTP service, that service could just act as a proxy to GitLab Pages over HTTPS, no?
>HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs.
If you are in a legal/political environment that allows active attacks by an ISP on their customers then you have a much bigger problem than just this sort of thing.
If you are in a legal/political environment that allows active attacks by an ISP on their customers then you have a much bigger problem than just this sort of thing.
Comcast in the US has injected content into non-secured pages to notify customers of things. That is a horrible business practice that should not be allowed.
What can I, an individual with nearly zero political clout (I can vote... but I live in a gerrymandered district... another layer to the problem!) do to get this problem fixed? Best case scenario, I say something, it goes viral, people march in protest against bad ISPs, the monopolies get broken up, etc. But how long does that all take?
Meanwhile, I'll only use HTTPS websites as a first-line of defense. The "much bigger problem" can be solved in parallel.
What can I, an individual with nearly zero political clout (I can vote... but I live in a gerrymandered district... another layer to the problem!) do to get this problem fixed? Best case scenario, I say something, it goes viral, people march in protest against bad ISPs, the monopolies get broken up, etc. But how long does that all take?
Meanwhile, I'll only use HTTPS websites as a first-line of defense. The "much bigger problem" can be solved in parallel.
"It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser." https://www.internetsociety.org/resources/deploy360/dane/
Isn't it then possible, albeit harder to do a MITM attack at this point with HTTPS?
Isn't it then possible, albeit harder to do a MITM attack at this point with HTTPS?
If you've decided that you trust the "firewall or other device", perhaps because you purchased it, or because doing so is a condition of employment, then you get to keep both halves.
If the "firewall or other device" tries to interpose when you don't trust it, that won't work, for the same reason it doesn't work for bad guys. We do not distinguish the apparent reason for attempts to destroy the confidentiality, integrity or authenticity promises in TLS, whatever the apparent motive your HTTP transaction will either work, delivering those promises or you get an error and no progress is made.
If the "firewall or other device" tries to interpose when you don't trust it, that won't work, for the same reason it doesn't work for bad guys. We do not distinguish the apparent reason for attempts to destroy the confidentiality, integrity or authenticity promises in TLS, whatever the apparent motive your HTTP transaction will either work, delivering those promises or you get an error and no progress is made.
This has happened in both USA & UK; in Toronto Canada, my top-2-in-the-country ISP has hijacked DNS, hijacked 404, and injected "helpful ads" at times. Every time there was a substantial backlash, but that came in on the nerds + grassroots level, not because of pre-existing laws.
"you" and clients connecting to your server might be different entities.
Thanks; #1 is the most persuasive argument for the type of site I'm envisioning (and likely massive part of "remaining 15%"). While a lot of other arguments in comments are not persuasive because they don't seem a feasible or relevant threat vector, a non-specific, generic injection of ads/malware makes more sense as a legitimate threat vector such a site could get caught in.
A fair question deserving a real answer, rather than downvotes.
It gets downvoted because this idea ("my site isn't sensitive so I don't want https") gets brought up and refuted every time LE or HTTPS comes up and it's getting old.
It gets downvoted because this idea ("my site isn't sensitive so I don't want https") gets brought up and refuted every time LE or HTTPS comes up and it's getting old.
While your website might not contain anything interesting, leaving it on HTTP leaves the door open for an attacker to put something nefarious on there, which you wouldn't want even if the current content is low stakes.
I would say that the main problem is not the encryption itself but the certificate that must be issued.
It’s sad we can’t just encrypt the communication by setting up something in the server and that would be it.
It’s sad we can’t just encrypt the communication by setting up something in the server and that would be it.
> It’s sad we can’t just encrypt the communication by setting up something in the server and that would be it.
You can? With any of Let's Encrypt's clients ( certbot, lego) of web servers that come with an ACME integration ( Caddy, Traefik).
You can? With any of Let's Encrypt's clients ( certbot, lego) of web servers that come with an ACME integration ( Caddy, Traefik).
I think the problem is if you use a self-signed certificate, the web browser tells you this is a grave concern. In order to avoid this issue, ACME requires your web server to communicate with an external service provider to sign the certificate. But now you're dependent on Lets Encrypt being able to access your server!
I'm not sure that this is an avoidable problem. If your web browser would accept an unsigned certificate, then it's not really encrypted content. The router could intercept the relevant HTTPS request, connect to the self-signed server on its own accord and pass the data back to the client. All we're achieving there is the use of a few more CPU cycles.
Lets Encrypt gives you proof that at some point in the last 90 days, Lets Encrypt's routes, which you trust to be more secure than your own routes, were able to access this server (modulo pedantry). If this information is interesting to you, you need to distinguish between the occasions when you have some alternative means of trust from the majority case. Browser warning pages are an in-your-face but reasonable approach.
As a person who has a vague understanding of how PKI works and a relative ability to distinguish "I want to access this site now" from "I have a means of proving that I trust this key", I would appreciate it if I could say I trust this signer or do something like trivially set up an acme signer for my home network.[*] The browser's "permanently stop caring about trust for this site" isn't really one that I enjoy using (even the old fashioned option to "add a temporary exception" was better!), and a lot of software is becoming harder to use without TLS.
[*] ed to add: I mean I can, but it's matter of time and energy. I think Windows makes it relatively easy to add a new root key, and on Linux I guess it's a matter of doing all the stuff you do whenever you configure stuff. On Android I have no idea if it's possible or if I just have to trust exactly whoever it is that OnePlus trusts. I've seen tutorials for how to deal with some of this stuff, and I always filed it into the box of things to deal with when I got a round tuit. It's not so much the ability to deal with it, as the fact that it's a fair amount of work, needs to be repeated for several devices, needs to be repeated for new devices, may not be doable for all devices, and it's done so rarely that it's completely impossible to memorise and even if you could something has probably changed in the interim. In short, it's possible, but using HTTP is way easier despite the fact that sometimes you have to override defaults.
I'm not sure that this is an avoidable problem. If your web browser would accept an unsigned certificate, then it's not really encrypted content. The router could intercept the relevant HTTPS request, connect to the self-signed server on its own accord and pass the data back to the client. All we're achieving there is the use of a few more CPU cycles.
Lets Encrypt gives you proof that at some point in the last 90 days, Lets Encrypt's routes, which you trust to be more secure than your own routes, were able to access this server (modulo pedantry). If this information is interesting to you, you need to distinguish between the occasions when you have some alternative means of trust from the majority case. Browser warning pages are an in-your-face but reasonable approach.
As a person who has a vague understanding of how PKI works and a relative ability to distinguish "I want to access this site now" from "I have a means of proving that I trust this key", I would appreciate it if I could say I trust this signer or do something like trivially set up an acme signer for my home network.[*] The browser's "permanently stop caring about trust for this site" isn't really one that I enjoy using (even the old fashioned option to "add a temporary exception" was better!), and a lot of software is becoming harder to use without TLS.
[*] ed to add: I mean I can, but it's matter of time and energy. I think Windows makes it relatively easy to add a new root key, and on Linux I guess it's a matter of doing all the stuff you do whenever you configure stuff. On Android I have no idea if it's possible or if I just have to trust exactly whoever it is that OnePlus trusts. I've seen tutorials for how to deal with some of this stuff, and I always filed it into the box of things to deal with when I got a round tuit. It's not so much the ability to deal with it, as the fact that it's a fair amount of work, needs to be repeated for several devices, needs to be repeated for new devices, may not be doable for all devices, and it's done so rarely that it's completely impossible to memorise and even if you could something has probably changed in the interim. In short, it's possible, but using HTTP is way easier despite the fact that sometimes you have to override defaults.
>In order to avoid this issue, ACME requires your web server to communicate with an external service provider to sign the certificate. But now you're dependent on Lets Encrypt being able to access your server!
Only if you're using the HTTP challenge, the DNS challenge is (IMO at least) much simpler, easier, doesn't require any services open to the internet so can work in a LAN, and can issue wildcard certs too.
If you use a webserver like Caddy as well, then your SSL certs are done automatically without you needing to do much of anything at all.
Only if you're using the HTTP challenge, the DNS challenge is (IMO at least) much simpler, easier, doesn't require any services open to the internet so can work in a LAN, and can issue wildcard certs too.
If you use a webserver like Caddy as well, then your SSL certs are done automatically without you needing to do much of anything at all.
That's true, and instead of verifying that Lets Encrypt can contact your server, they verify that you can control the DNS. It isn't compatible with least privilege though, is it?
Either every box that wants to use SSL has to be capable of changing DNS settings, or you need a central box that generates secrets and securely transmits them to the servers.
I have domain names which I am authorised to serve content on, but not authorised to manipulate DNS for (but they're all exposed to the internet, so not relevant to the limitation - but probably the reason I overlooked the blindingly obvious solution)
Either every box that wants to use SSL has to be capable of changing DNS settings, or you need a central box that generates secrets and securely transmits them to the servers.
I have domain names which I am authorised to serve content on, but not authorised to manipulate DNS for (but they're all exposed to the internet, so not relevant to the limitation - but probably the reason I overlooked the blindingly obvious solution)
Super agree with this comment. Been using Caddy with DNS and it's been amazing.
> I think the problem is if you use a self-signed certificate, the web browser tells you this is a grave concern. In order to avoid this issue, ACME requires your web server to communicate with an external service provider to sign the certificate. But now you're dependent on Lets Encrypt being able to access your server!
Not necessarily, you can use lego client with dns01 challenge. This is how I issue certificates for local services running with dnsmasq or hosts file.
Not necessarily, you can use lego client with dns01 challenge. This is how I issue certificates for local services running with dnsmasq or hosts file.
No it doesn't. Having HTTP does not magically open the server.
No, it doesn't.
SSL doesn't magically secure your servers, especially not if all you are doing is serving static HTML content and images.
All HTTPS really does is encrypt the HTTP traffic while it is in transit. The main reason this is important is because someone monitoring network traffic (for example, at the network switch) could theoretically see raw passwords and stuff being sent over the wire in plain text.
If your web site doesn't do anything with user names and passwords or form fields that accept some type of text that needs to be secured, then HTTPS isn't really doing jack shit for you (other than making visitors "feel" secure).
Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.
SSL doesn't magically secure your servers, especially not if all you are doing is serving static HTML content and images.
All HTTPS really does is encrypt the HTTP traffic while it is in transit. The main reason this is important is because someone monitoring network traffic (for example, at the network switch) could theoretically see raw passwords and stuff being sent over the wire in plain text.
If your web site doesn't do anything with user names and passwords or form fields that accept some type of text that needs to be secured, then HTTPS isn't really doing jack shit for you (other than making visitors "feel" secure).
Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.
> Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.
Not just governments. I can get in my car and go to the three main shopping malls in my relatively large Portuguese city. I will very easily MITM a bunch of people there, no problem, using a variety of attacks. They won't realize that I'm now sucking all their traffic in and modifying it as I please.
After I've done that, if they visit any HTTP link, I can inject whatever I want there: crypto mining, download links to a modified/hacked version of their browser, social engineering attacks (phishing), cookie hijacking, etc. Notice how I can modify whatever HTTP page you have to link to websites you think are secure (banks, social media, websites), but that are modified (e.g. via sslstrip, or just by being similar-but-not-quite-the-same-hosts, etc)
Many months ago I went through this here: https://news.ycombinator.com/item?id=25123366
It should be a duty for all sysadmins to make sure their sites are HTTPS. Sure, if they're only in an intranet, HTTPS is likely overkill. But any publicly hosted website should be forced to be HTTPS.
One single HTTP website leaves a person vulnerable to millions of attacks. Many of these are still present on the web with HTTPS -- but at least then they'll typically be done by the people running the HTTPS site, not by someone in the middle.
Not just governments. I can get in my car and go to the three main shopping malls in my relatively large Portuguese city. I will very easily MITM a bunch of people there, no problem, using a variety of attacks. They won't realize that I'm now sucking all their traffic in and modifying it as I please.
After I've done that, if they visit any HTTP link, I can inject whatever I want there: crypto mining, download links to a modified/hacked version of their browser, social engineering attacks (phishing), cookie hijacking, etc. Notice how I can modify whatever HTTP page you have to link to websites you think are secure (banks, social media, websites), but that are modified (e.g. via sslstrip, or just by being similar-but-not-quite-the-same-hosts, etc)
Many months ago I went through this here: https://news.ycombinator.com/item?id=25123366
It should be a duty for all sysadmins to make sure their sites are HTTPS. Sure, if they're only in an intranet, HTTPS is likely overkill. But any publicly hosted website should be forced to be HTTPS.
One single HTTP website leaves a person vulnerable to millions of attacks. Many of these are still present on the web with HTTPS -- but at least then they'll typically be done by the people running the HTTPS site, not by someone in the middle.
It seems firesheep[0] is fading from the internet's institutional memory. Seeing it action was startling for most of us at the time.
[0] https://en.wikipedia.org/wiki/Firesheep
[0] https://en.wikipedia.org/wiki/Firesheep
Security is about the ”CIA triad“, i.e. confidentiality, integrity, and availability.
For those sites you mention, confidentiality and availability will not really be impacted by HTTPS.
But the integrity can be.
Case in point: See this comment https://news.ycombinator.com/item?id=27507826
For those sites you mention, confidentiality and availability will not really be impacted by HTTPS.
But the integrity can be.
Case in point: See this comment https://news.ycombinator.com/item?id=27507826
HTTPS is definitely useful for preserving the integrity of data between the server and the end user.
To be clear, I'm very pro-SSL and have used LetsEncrypt for years on all my domains. I was just taking issue with the notion that someone's web server serving static content could be breached just because it didn't have an SSL cert.
To be clear, I'm very pro-SSL and have used LetsEncrypt for years on all my domains. I was just taking issue with the notion that someone's web server serving static content could be breached just because it didn't have an SSL cert.
I mean define breached? I don't think anyone ever would say that without TLS you can use HTTP to drop into a shell on the server. But you can, largely arbitrarily, mess with the content of the site if you're adjacent to either the sever or client, or in the path between them. Maybe this matters a lot for someone's security, maybe it doesn't at all.
I had the same feeling as you recently, until I read a site posted here a few weeks ago. I can't find it now, but it was a personal page where someone described in increasing levels of severity what can be done over an unsecured HTTP connection even if there is no private data transmitted over it. Can someone help?
Because unencrypted HTTP allows attackers to MITM the traffic, they can do things like put ads on your site, inject malware or bitcoin miners, or just replace your site completely. None of those affect you, the site owner, directly, but ìt subverts the purpose of your site and lowers the value and trustworthiness of your site to your visitors.
Because unencrypted HTTP allows attackers to MITM the traffic, they can do things like put ads on your site, inject malware or bitcoin miners, or just replace your site completely. None of those affect you, the site owner, directly, but ìt subverts the purpose of your site and lowers the value and trustworthiness of your site to your visitors.
Most anyone who is in a position to reliably MITM an HTTP site would also be in a position to install a certificate source (either as part of a “install this to access the web” program or similar).
It’s a necessary level of defense but it is NOT sufficient- especially if you never check certificates.
It’s a necessary level of defense but it is NOT sufficient- especially if you never check certificates.
Not really. In my experience it's always been an ISP that modified the HTTP in transit (to add their own advertising and analytics JavaScript inline), and the ISP didn't have the ability to install a certificate source.
I highly recommend you do a search for Firesheep - the tool that really started the push for HTTPS everywhere. You're right that a malicious network operator would be in a position to request users install root certs, but the problems with plaintext HTTP are deeper than just that.
Frankly, I feel it's very good, because at this point you notice your network has been hijacked and this is the first step to solve the problem. Patching it with HTTPS (especially without HSTS) won't solve the problem, it will just make it more difficult to discover by an unsuspecting user.
So let's say your site is popular. What exactly is preventing a bad actor from MITM your site and spreading malware at a coffee shop or insert open public wifi?
HTTPS isn't just about securing the information, it ensures that when someone tries to get to your site, they ACTUALLY get to your site.
HTTPS isn't just about securing the information, it ensures that when someone tries to get to your site, they ACTUALLY get to your site.
There are many assumptions here. Personally I don't even remember when I connected to an open wifi, I believe some systems will prevent you from doing so. In any case, using HTTPS is indeed helpful in a hostile network when combined with HSTS, but if you have already connected to a network controlled by an attacker, this means they can not only sniff all your traffic, but already control your DNS and can easily find multiple ways to deliver the payload to you.
> Personally I don't even remember when I connected to an open wifi, I believe some systems will prevent you from doing so.
If that's the case, you are absolutely not the average internet user. Plenty of people, most of them non-technical, will connect to the wifi of their local cafe, and spend many tens of minutes doing things on the internet while connected to it.
If that's the case, you are absolutely not the average internet user. Plenty of people, most of them non-technical, will connect to the wifi of their local cafe, and spend many tens of minutes doing things on the internet while connected to it.
you can publish a sha256 hash for every site/resource. (just kidding of course)
If the only things on your site are resources for other sites, you could actually make this work using a technology called Subresource Integrity where the hashes live in the link origin (and the browser verifies the content matches the hash on load).
Unfortunately SRI is only deployed for CSS and Javascript (so your collection of JPEGs, or videos, or text snippets aren't eligible unless you somehow wrap them as a Javascript which is horrible) and most sites will themselves be HTTPS so they don't want to have active links (even with SRI) to non-HTTPS sites.
Unfortunately SRI is only deployed for CSS and Javascript (so your collection of JPEGs, or videos, or text snippets aren't eligible unless you somehow wrap them as a Javascript which is horrible) and most sites will themselves be HTTPS so they don't want to have active links (even with SRI) to non-HTTPS sites.
No kid, SRI : Sub Resource Integrity is exactly this and an important way to secure CDN hosted js you are using on your site, however if the channel itself has no integrity protection, like HTTP does not (but https does via TLS), an attacker can dynamically replace SRI values with their malicious equivalents. So, both?
yeah that's why I said just kidding. basically you would need to host your sha hashes somewhere else, which is probably a little bit wierd. also sub resource integrity, only works with sub resources ;-) (and I think sub resource integrity is stupid, because the future is only useful for external resources, which you should trust?! I would never trust external resources)
The current Let's Encrypt tooling (certbot and company) is far from the simplest way to handle HTTPS / TLS. I think the simplest solution is a webserver with built-in ACME tls-alpn-01 support. That doesn't require listening on HTTP separately, and it works automatically without needing anything but the domain name. No "mucking about with certs" at all; just a single server listening on port 443 that's automatically secure. Apache supports this via mod_md; Caddy has this as a flagship feature; many other web servers support this as well.
I do think there's high value in having 100% of Internet traffic encrypted, not just 99%.
Consider something like the Great Cannon attack: someone could intercept traffic to your site and add in malicious JavaScript, or references to large resources on other sites for a DoS, or references to LAN resources, or other things that use your site to hurt others.
Consider that we're moving to a more carefully sandboxed, permission-based web, and those permissions are tied to identity. If your site wants permission for location, or permission to autoplay video, or camera access, or any number of other things that we may want to limit access to, that permission needs to be tied to a site identity so that they're not available to anyone who MITMs your site.
Consider that if your site has any kind of form, even the simplest of forms, users may use autofill with it, which puts them at risk if your site is plaintext.
Consider that even if your site is 100% static, it could have ads or other JavaScript injected into it.
Consider that what's "non-controversial" for you may not be non-controversial to everyone browsing your site; you're encrypting for their benefit, not just for yours.
Consider that it's much easier to keep users secure when browsers mark http as explicitly insecure rather than just omitting security icons.
We should absolutely make HTTPS even simpler and easier, so that security becomes the zero-effort default. And we should continue to deprecate HTTP.
As a related aside, I do think there are some specific cases that haven't yet been well-handled by HTTPS. In particular, there isn't yet a great solution for routers and embedded devices, which need an identity but don't have a domain name for that identity.
I do think there's high value in having 100% of Internet traffic encrypted, not just 99%.
Consider something like the Great Cannon attack: someone could intercept traffic to your site and add in malicious JavaScript, or references to large resources on other sites for a DoS, or references to LAN resources, or other things that use your site to hurt others.
Consider that we're moving to a more carefully sandboxed, permission-based web, and those permissions are tied to identity. If your site wants permission for location, or permission to autoplay video, or camera access, or any number of other things that we may want to limit access to, that permission needs to be tied to a site identity so that they're not available to anyone who MITMs your site.
Consider that if your site has any kind of form, even the simplest of forms, users may use autofill with it, which puts them at risk if your site is plaintext.
Consider that even if your site is 100% static, it could have ads or other JavaScript injected into it.
Consider that what's "non-controversial" for you may not be non-controversial to everyone browsing your site; you're encrypting for their benefit, not just for yours.
Consider that it's much easier to keep users secure when browsers mark http as explicitly insecure rather than just omitting security icons.
We should absolutely make HTTPS even simpler and easier, so that security becomes the zero-effort default. And we should continue to deprecate HTTP.
As a related aside, I do think there are some specific cases that haven't yet been well-handled by HTTPS. In particular, there isn't yet a great solution for routers and embedded devices, which need an identity but don't have a domain name for that identity.
Most people have already answered you. The problem is anyone in the middle can hijack the page and put whatever they want there. See what I mentioned here in the past: https://news.ycombinator.com/item?id=25123366
Now imagine you combine MITM-ing someone with social engineering. You send them a legitimate inocuous link like http://my-bank.my-tld, but you are MITM-ing them and outright replace the content of the page with whatever you want. Yes, HSTS protects agains this example, but the problem still remains: whatever goes through HTTP can be manipulated and used for nefarious ends. It's kinda like walking around with a car door open waiting for someone to throw a bomb inside it.
Now imagine you combine MITM-ing someone with social engineering. You send them a legitimate inocuous link like http://my-bank.my-tld, but you are MITM-ing them and outright replace the content of the page with whatever you want. Yes, HSTS protects agains this example, but the problem still remains: whatever goes through HTTP can be manipulated and used for nefarious ends. It's kinda like walking around with a car door open waiting for someone to throw a bomb inside it.
From what I understand, one of the main issues with HTTP is that anyone in the middle can just change the content.
Which is exactly the problem DNSoTLS and DNSoHTTPS solve for DNS but there seems to be a lot more resistance on that front. I guess if a whole generation of ad-blockers has been based on Squid the tune would change I guess.
Doesn't DoH/DoT centralise a decentralised protocol though? DoH is great but then you just get Cloudflare knowing all the DNS calls.
No, but also yes. I mean DNS and DoT have the same relationship as HTTP and HTTPS but unlike the HTTPS rollout large projects aren't waiting around for the world to upgrade all their software and are just connecting to public DNS servers that speak DoT/H.
DNS the global database is still just as decentralized but DNS thing you connect to do the actual work is now a little less so.
DNS the global database is still just as decentralized but DNS thing you connect to do the actual work is now a little less so.
No, as everyone (including your ISP) can setup a DoH/DoT server. What is a problem though is a lack of discoverability. Right now you need to manually configure DoT/DoH. Or you are Mozilla and force the decision.
IIRC If you have Chrome in some cases it will auto-detect an upgrade. So e.g. you've told Chrome you want 8.8.8.8 DNS, that can do DoH, so Chrome will use DoH from 8.8.8.8
From Google's point of view even if they auto-upgrade you from your ISP's DNS server to an ISP-controlled DoH server this is a win because the DoH server paperwork (to get that upgrade to happen) requires the ISP to have sane rules for the new shiny DoH server whereas their old DNS server was whatever Corporate said it should be.
e.g. DoH has an explicit censorship mechanism. The server can say "Nah, I can't tell you that" rather than pretending the answer for your query is either NXDOMAIN when it isn't, or worse some custom ISP chosen IP that isn't even a sane answer to the question you asked.
This means (if DoH servers implement it, which Google requires to get that auto-upgrade behaviour) software using DoH can do much less crazy acrobatics to cope with censorship than with DNS. For example that bogus IP trick obviously can't work with HTTPS. So users get a weird HTTPS error, and it's unclear why they can't look at Clown Porn. Whereas with DoH the browser can say "You are not allowed to look at Clown Porn". Much better.
[This is independent of the question of whether censoring Clown Porn is a good idea, sometimes, or always, which is not a technical problem and so out of scope for DoH. People are doing it, and we want to make that cause less technical problems]
From Google's point of view even if they auto-upgrade you from your ISP's DNS server to an ISP-controlled DoH server this is a win because the DoH server paperwork (to get that upgrade to happen) requires the ISP to have sane rules for the new shiny DoH server whereas their old DNS server was whatever Corporate said it should be.
e.g. DoH has an explicit censorship mechanism. The server can say "Nah, I can't tell you that" rather than pretending the answer for your query is either NXDOMAIN when it isn't, or worse some custom ISP chosen IP that isn't even a sane answer to the question you asked.
This means (if DoH servers implement it, which Google requires to get that auto-upgrade behaviour) software using DoH can do much less crazy acrobatics to cope with censorship than with DNS. For example that bogus IP trick obviously can't work with HTTPS. So users get a weird HTTPS error, and it's unclear why they can't look at Clown Porn. Whereas with DoH the browser can say "You are not allowed to look at Clown Porn". Much better.
[This is independent of the question of whether censoring Clown Porn is a good idea, sometimes, or always, which is not a technical problem and so out of scope for DoH. People are doing it, and we want to make that cause less technical problems]
Depending on ISP and country this can never be achived. Sometimes there are laws to filter out specific domains.
But then again, should the browser be the authority to decide that? I think not.
But then again, should the browser be the authority to decide that? I think not.
What exactly is it that "can never be achived" ?
Technically as I explained DoH is content that you can't tell the client about some particular name, it just wants that expressed as an HTTP code (e.g. 403 Forbidden) rather than lying in your DNS answers.
But over the longer term this is all irrelevant, the names are just a convention, legislators can write a law about names, but our laws aren't like Mother Nature's, people can just ignore them unless you deliver the will and resources to enforce them. Imagine if your legislature passes a law forbidding you from thinking about cats. Does it work? Do you stop thinking about cats? No? How will they make you?
In technical terms the immediate future is Encrypted Client Hello (the names cease to be transported in plain text on the wire so an eavesdropper can't enforce a law about names) and then Oblivious DNS (the popular DNS server you're talking to such as 8.8.8.8 or 1.1.1.1 wouldn't know what question you asked, nor what the answer was, so it can't obey a law about names even if it wanted to).
Technically as I explained DoH is content that you can't tell the client about some particular name, it just wants that expressed as an HTTP code (e.g. 403 Forbidden) rather than lying in your DNS answers.
But over the longer term this is all irrelevant, the names are just a convention, legislators can write a law about names, but our laws aren't like Mother Nature's, people can just ignore them unless you deliver the will and resources to enforce them. Imagine if your legislature passes a law forbidding you from thinking about cats. Does it work? Do you stop thinking about cats? No? How will they make you?
In technical terms the immediate future is Encrypted Client Hello (the names cease to be transported in plain text on the wire so an eavesdropper can't enforce a law about names) and then Oblivious DNS (the popular DNS server you're talking to such as 8.8.8.8 or 1.1.1.1 wouldn't know what question you asked, nor what the answer was, so it can't obey a law about names even if it wanted to).
Once upon a time I used privoxy. It was a local HTTP non-caching proxy that let you process HTML requests and came with adblocking scripts you could enable. There were certain advantages to that model compared to current browser plugins. But I'm happy to pay no privoxy as a cost of HTTPS. There's reasons for that though: e.g. today, web browsers generally act as platforms that allow us to write ad blockers inside them. Will I be able to plug into my own DNSoTLS clients?
first off, let me say, for me. I use Caddy (https://caddyserver.com/) and it just works. You start it, it gets a cert from letsencrypt and starts serving https. So it was (almost) zero work to serve with https.
As for reasons to encrypt
1. Prevents (I think) ISPs in the middle from injecting ads, spyware, phishing scams, etc on top of your site.
2. Prevents 3rd parties from seeing what pages the user is accessing. Some people would prefer that other's can not read over their shoulder and see what they're reading.
I know for me, I'm sensitive to that particular issue to the point that I don't really want to use Netflix, Amazon Prime, Spotify, etc. I really don't like the idea that they're building a profile of me based on what I watch and thinking they know who I am based on that.
It could be as simple as I don't want it known if I'm reading liberal or conservative blogs.
I'm sure others might have other reasons they don't want a 3rd party to know what specific pages they're reading.
---
ps: I get there are other ways to track me but I'm fairly confident that I'm avoiding most of them via HTTPS, VPNs, Private browser windows, multiple profiles, 3rd party cookies off, ad blockers, etc....
As for reasons to encrypt
1. Prevents (I think) ISPs in the middle from injecting ads, spyware, phishing scams, etc on top of your site.
2. Prevents 3rd parties from seeing what pages the user is accessing. Some people would prefer that other's can not read over their shoulder and see what they're reading.
I know for me, I'm sensitive to that particular issue to the point that I don't really want to use Netflix, Amazon Prime, Spotify, etc. I really don't like the idea that they're building a profile of me based on what I watch and thinking they know who I am based on that.
It could be as simple as I don't want it known if I'm reading liberal or conservative blogs.
I'm sure others might have other reasons they don't want a 3rd party to know what specific pages they're reading.
---
ps: I get there are other ways to track me but I'm fairly confident that I'm avoiding most of them via HTTPS, VPNs, Private browser windows, multiple profiles, 3rd party cookies off, ad blockers, etc....
If privacy is a concern, users should also consider switching to an independent DoS/DoT DNS provider.
Encryption isn't just about hiding information, it's also about ensuring that nobody tampered with it.
Hacked routers can easily insert malware (and now days crypotminers) into html/javascript/css payloads, hell I remember playing with some stuff decades ago that would allow you to inject malware into exes that came across the network without encryption.
Hacked routers can easily insert malware (and now days crypotminers) into html/javascript/css payloads, hell I remember playing with some stuff decades ago that would allow you to inject malware into exes that came across the network without encryption.
[deleted]
>But I'm still unconvinced that every single one of those last remaining 15% of websites must be transitioned to HTTPS.
I use HTTPS. That said, if someone doesn't want to do it - also a valid choice. The arguments have been made (content manipulation, snooping ...) but if I as a site owner don't care about someone elses shitty ISP, then I can use HTTP only.
I use HTTPS. That said, if someone doesn't want to do it - also a valid choice. The arguments have been made (content manipulation, snooping ...) but if I as a site owner don't care about someone elses shitty ISP, then I can use HTTP only.
Yes, that 15% includes my personal site.
But let's be real, Apple, Google and Microsoft provide the money funding the browsers 95% of people use. So I think we can predict where this will end up.
But let's be real, Apple, Google and Microsoft provide the money funding the browsers 95% of people use. So I think we can predict where this will end up.
ISPs can inject content into HTTP pages. This alone is a reason to move to HTTPS across the board.
While I'm all for supporting Let's Encrypt, I think it showcases something very wrong with the www, which is a heavy reliance on centralized entities that eventually become single points of failure.
That being said, as long as we're on that space let's use HTTPS and support Let's Encrypt.
That being said, as long as we're on that space let's use HTTPS and support Let's Encrypt.
The nature of (user friendly) CAs requires centralization. You can always sign your own certs and distribute them -- nothing is stopping you aside from a poor user experience.
Tor/OnionShare is at this point a better user experience than self-signed certificates.
well there would be DANE, but that will only solve encryption and not authorization (in the sense of google.com is really run by google inc.)
I really really wish LetsEncrypt would support 1 year long certificates.
Round Robin DNS isn't really supported "easily" so for those sites & others, manually replacing certs every year would be a more practical option.
To generate revenue, they should charge for stronger business confirmation like all the other for-profit certs.
Round Robin DNS isn't really supported "easily" so for those sites & others, manually replacing certs every year would be a more practical option.
To generate revenue, they should charge for stronger business confirmation like all the other for-profit certs.
The long term goal, supported by Let's Encrypt, is that almost everybody should stop "manually replacing certs".
When Let's Encrypt launched, the rule was 39 months. You could buy a certificate in 2015 and not need to replace it until 2018. If you had typical accounting practices a server might only ever need two certificates between when it's first purchased and installed and when it is finally retired and sent for scrap.
Ryan Sleevi and co. fought for two years and eventually got 825 days.
But in 2020 Apple unilaterally announced that they'd decided they didn't respect the line in the sand on this issue from mostly for-profit CAs, and their policy would require a maximum lifetime of 398 days.
You should not depend on this as the last word. I can certainly see less than 100 days being required later this decade.
As to "stronger business confirmation" it's essentially worthless. The client software doesn't enforce stuff you think you read in a certificate, because it doesn't understand it. The SANs can be understood by a machine so those are enforced, but nothing else is.
Example: When you visit google.com, your browser silently and automatically verifies at each step that this is really google.com, by doing effectively memcmp(dnsName, "google.com") for every single HTTPS transaction. That's mindless work so it can get it correct without bothering you. But even if the certificate includes Google's business number and postal address (which it does not) the browser can't match those against anything, they're just gibberish to a machine. It entirely ignores these values.
So: If at any step the remote site can't prove it is google.com, that fails immediately. Suppose you're typing in your password, the HTML form loaded just fine, and now it's just a POST to submit. During that POST the browser verifies, as it always does, that this is google.com. But if the business is now named "Bob's Toys" of "1234 Toy Town, Nowhere" it doesn't know that's wrong, your password will be sent anyway. Most likely after the password is sent, the response is a 30x HTTP code, and the browser fetches a different URL, which might incur a new HTTPS connection with a new certificate. So the "Bob's Toys" certificates was never seen by a human (you) at all, and the browser doesn't know who Bob's Toys are or that they're not google.com, it only checks that the DNS names match.
Only DNS names matter. Maybe you're happy about that, maybe you're sad, but it won't stop being true either way.
When Let's Encrypt launched, the rule was 39 months. You could buy a certificate in 2015 and not need to replace it until 2018. If you had typical accounting practices a server might only ever need two certificates between when it's first purchased and installed and when it is finally retired and sent for scrap.
Ryan Sleevi and co. fought for two years and eventually got 825 days.
But in 2020 Apple unilaterally announced that they'd decided they didn't respect the line in the sand on this issue from mostly for-profit CAs, and their policy would require a maximum lifetime of 398 days.
You should not depend on this as the last word. I can certainly see less than 100 days being required later this decade.
As to "stronger business confirmation" it's essentially worthless. The client software doesn't enforce stuff you think you read in a certificate, because it doesn't understand it. The SANs can be understood by a machine so those are enforced, but nothing else is.
Example: When you visit google.com, your browser silently and automatically verifies at each step that this is really google.com, by doing effectively memcmp(dnsName, "google.com") for every single HTTPS transaction. That's mindless work so it can get it correct without bothering you. But even if the certificate includes Google's business number and postal address (which it does not) the browser can't match those against anything, they're just gibberish to a machine. It entirely ignores these values.
So: If at any step the remote site can't prove it is google.com, that fails immediately. Suppose you're typing in your password, the HTML form loaded just fine, and now it's just a POST to submit. During that POST the browser verifies, as it always does, that this is google.com. But if the business is now named "Bob's Toys" of "1234 Toy Town, Nowhere" it doesn't know that's wrong, your password will be sent anyway. Most likely after the password is sent, the response is a 30x HTTP code, and the browser fetches a different URL, which might incur a new HTTPS connection with a new certificate. So the "Bob's Toys" certificates was never seen by a human (you) at all, and the browser doesn't know who Bob's Toys are or that they're not google.com, it only checks that the DNS names match.
Only DNS names matter. Maybe you're happy about that, maybe you're sad, but it won't stop being true either way.
I have mixed feelings. Let's Encrypt has pretty much wiped out the annoying middlebox industry. But they've also wiped out TSL/SSL certs providing any solid info about who's behind the site. Now, nobody knows who's behind most web sites. The domain registrar industry failed us, supporting "domain privacy" for businesses. Then the certificate industry failed us, allowing issuance of anonymous SSL/TLS certs. Then Amazon allowed sellers to be anonymous while claiming that Amazon itself was not the seller.
Amazon has been investigated for selling dangerously defective electrical products.[1] But they've been allowed to sleaze by, claiming that some anonymous seller is the problem.
[1] https://www.wsj.com/articles/amazon-has-ceded-control-of-its...
Amazon has been investigated for selling dangerously defective electrical products.[1] But they've been allowed to sleaze by, claiming that some anonymous seller is the problem.
[1] https://www.wsj.com/articles/amazon-has-ceded-control-of-its...
> But they've also wiped out TSL/SSL certs providing any solid info about who's behind the site.
Did DV certs really require personal info before? I thought that was only ever EV.
> The domain registrar industry failed us, supporting "domain privacy" for businesses.
They didn't fail, they decided that maybe publishing the home address of every site owner was maybe actually a terrible idea and a huge privacy issue.
> Then Amazon allowed sellers to be anonymous while claiming that Amazon itself was not the seller.
That feels unrelated, but: Then get a court order and force the issue.
Did DV certs really require personal info before? I thought that was only ever EV.
> The domain registrar industry failed us, supporting "domain privacy" for businesses.
They didn't fail, they decided that maybe publishing the home address of every site owner was maybe actually a terrible idea and a huge privacy issue.
> Then Amazon allowed sellers to be anonymous while claiming that Amazon itself was not the seller.
That feels unrelated, but: Then get a court order and force the issue.
Businesses are not entitled to anonymity.
California law: (B&P code 17538).
(1) Before accepting any payment or processing any debit or credit charge or funds transfer, the vendor shall disclose to the buyer in writing or by electronic means of communication, such as e-mail or an on-screen notice, the vendor’s return and refund policy, the legal name under which the business is conducted and, except as provided in paragraph (3) (which is about PO boxes), the complete street address from which the business is actually conducted.
Not even in the European Union. In fact, especially not in the European Union. One of the principles of the Single Market is that you can't escape liability by operating in a different country within the Union.[1]
"Definitions ... (b) "service provider": any natural or legal person providing an information society service; ...
General information to be provided
1. In addition to other information requirements established by Community law, Member States shall ensure that the service provider shall render easily, directly and permanently accessible to the recipients of the service and competent authorities, at least the following information:
(a) the name of the service provider;
(b) the geographic address at which the service provider is established;
(c) the details of the service provider, including his electronic mail address, which allow him to be contacted rapidly and communicated with in a direct and effective manner;"
[1] https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX...
California law: (B&P code 17538).
(1) Before accepting any payment or processing any debit or credit charge or funds transfer, the vendor shall disclose to the buyer in writing or by electronic means of communication, such as e-mail or an on-screen notice, the vendor’s return and refund policy, the legal name under which the business is conducted and, except as provided in paragraph (3) (which is about PO boxes), the complete street address from which the business is actually conducted.
Not even in the European Union. In fact, especially not in the European Union. One of the principles of the Single Market is that you can't escape liability by operating in a different country within the Union.[1]
"Definitions ... (b) "service provider": any natural or legal person providing an information society service; ...
General information to be provided
1. In addition to other information requirements established by Community law, Member States shall ensure that the service provider shall render easily, directly and permanently accessible to the recipients of the service and competent authorities, at least the following information:
(a) the name of the service provider;
(b) the geographic address at which the service provider is established;
(c) the details of the service provider, including his electronic mail address, which allow him to be contacted rapidly and communicated with in a direct and effective manner;"
[1] https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX...
Oh, I missed that we were talking about businesses. So long as individuals can stay private, I'm not sure I mind that, then.
You can divide the history of Web PKI certificates into three eras.
In the current era, the situation is that there are three acknowledged categories of certificates in the Web PKI (and thus trusted by an out-of-box web browser): EV, OV and DV. These are all defined by the Baseline Requirements, published by the CA/Browser Forum: https://cabforum.org/baseline-requirements-documents/
The BRs specify that certain characteristics of the X.509 Subject (e.g. a postal address) must be present in each category and if present they must be verified by some particular means. PKIX adds Subject Alternative Names SANs†, to reflect the Internet's idea about how to name things (e.g. Fully Qualified Domain Names), and in the modern era the BRs specify methods by which Certificate Authorities may verify those names belong to the applicant. I like to call these the Ten Blessed Methods, although today there are no longer ten of them.
In the prior era from about 2012 to 2017, things were similar except that the BRs said that any CA could verify SANs using "Any other method" of the CA's choosing. In practice this meant the methods in actual use were often inadequate and sometimes outright laughable.
Before that era, the CA/B rules didn't exist. Certificate Authorities occupied in effect a Wild West, having either been specialists providing X.509 certificates in other applications like the financial sector or else created specifically for this purpose. They did whatever they wanted. At first, they charged a lot of money for certificates full of details from the X.500 system. What was the full street address of your organisation? There was no systematisation, so given a certificate it would be a job for a forensic expert to decide what, if anything, could be said to be true about the subject and why. This worked OK when there were only a few dozen companies even bothering to use Netscape's new fangled HTTPS feature to secure credit card transactions. But if you can make $1000 selling one certificates to a bank, how about making $2000 by selling twenty $100 certificates to big commercial outfits keen to explore the possibilities for "Commerce on the Information Superhighway" ? Of course for $100 each you can't expect to check their street address. Let's just write the company's name, and "Verified".
So no, the answer to your question is that "DV Certificates" were never required to have personal info, but that's mostly because no certificates were in a sense required to fill that out, the rules about this stuff come after the de facto existence of DV certificates is driven by a race-to-the-bottom free market.
As to the Domain Registrars, for many of the TLDs we care about the registrar is, or is ultimately sanctioned by, a sovereign entity. Just as with Birth Registration, or Ship Registration, if you've got a problem with the way one country does it, take it up with that country, it's their business not yours.
In the UK for example businesses even those which are just a single person working under their name (such as my sister) are legally required to provide a postal address for their UK domain registration. Are some of them fake? Probably, lots of information in our legally required business register is fake, so that would be expected, but it is the law for whatever that's worth.
† Importantly, SANs are not an "alias". All certificates in the Web PKI have at least one SAN. Certificate Auhorities can, and as far as I know all do choose to write one of the names from a SAN as text into the X.509 Subject Common Name (CN) field. But that field is a legacy of the X.500 directory system that has been obsolete for decades, it's a plausible choice to display to a human because it's guaranteed to be human readable, for any other purpose it's definitely wrong.
In the current era, the situation is that there are three acknowledged categories of certificates in the Web PKI (and thus trusted by an out-of-box web browser): EV, OV and DV. These are all defined by the Baseline Requirements, published by the CA/Browser Forum: https://cabforum.org/baseline-requirements-documents/
The BRs specify that certain characteristics of the X.509 Subject (e.g. a postal address) must be present in each category and if present they must be verified by some particular means. PKIX adds Subject Alternative Names SANs†, to reflect the Internet's idea about how to name things (e.g. Fully Qualified Domain Names), and in the modern era the BRs specify methods by which Certificate Authorities may verify those names belong to the applicant. I like to call these the Ten Blessed Methods, although today there are no longer ten of them.
In the prior era from about 2012 to 2017, things were similar except that the BRs said that any CA could verify SANs using "Any other method" of the CA's choosing. In practice this meant the methods in actual use were often inadequate and sometimes outright laughable.
Before that era, the CA/B rules didn't exist. Certificate Authorities occupied in effect a Wild West, having either been specialists providing X.509 certificates in other applications like the financial sector or else created specifically for this purpose. They did whatever they wanted. At first, they charged a lot of money for certificates full of details from the X.500 system. What was the full street address of your organisation? There was no systematisation, so given a certificate it would be a job for a forensic expert to decide what, if anything, could be said to be true about the subject and why. This worked OK when there were only a few dozen companies even bothering to use Netscape's new fangled HTTPS feature to secure credit card transactions. But if you can make $1000 selling one certificates to a bank, how about making $2000 by selling twenty $100 certificates to big commercial outfits keen to explore the possibilities for "Commerce on the Information Superhighway" ? Of course for $100 each you can't expect to check their street address. Let's just write the company's name, and "Verified".
So no, the answer to your question is that "DV Certificates" were never required to have personal info, but that's mostly because no certificates were in a sense required to fill that out, the rules about this stuff come after the de facto existence of DV certificates is driven by a race-to-the-bottom free market.
As to the Domain Registrars, for many of the TLDs we care about the registrar is, or is ultimately sanctioned by, a sovereign entity. Just as with Birth Registration, or Ship Registration, if you've got a problem with the way one country does it, take it up with that country, it's their business not yours.
In the UK for example businesses even those which are just a single person working under their name (such as my sister) are legally required to provide a postal address for their UK domain registration. Are some of them fake? Probably, lots of information in our legally required business register is fake, so that would be expected, but it is the law for whatever that's worth.
† Importantly, SANs are not an "alias". All certificates in the Web PKI have at least one SAN. Certificate Auhorities can, and as far as I know all do choose to write one of the names from a SAN as text into the X.509 Subject Common Name (CN) field. But that field is a legacy of the X.500 directory system that has been obsolete for decades, it's a plausible choice to display to a human because it's guaranteed to be human readable, for any other purpose it's definitely wrong.
Even things like Extended Validation certificates have in the past shown themselves to be subject to relatively significant inaccuracies[1] if that's any sort of mixed comfort.
[1]https://scotthelme.co.uk/extended-validation-not-so-extended...
[1]https://scotthelme.co.uk/extended-validation-not-so-extended...
Okay so domain privacy isn’t so black and white. It sucks that this is where we are as a society but I don’t want strangers to be able to connect my name with my address in an easily searchable database. Without a domain privacy service I would have to buy a PO Box just to put a website on the internet.
The WHOIS database is an absolutely terrible idea that needs to die as soon as possible. This should have been a proxy service from the beginning. I don’t care if ICANN knows where I live so they can forward abuse mail but they should have never published this info to the public.
The WHOIS database is an absolutely terrible idea that needs to die as soon as possible. This should have been a proxy service from the beginning. I don’t care if ICANN knows where I live so they can forward abuse mail but they should have never published this info to the public.
But I'm still unconvinced that every single one of those last remaining 15% of websites must be transitioned to HTTPS.
I have personal websites that are open, public, non-controversial, simple. I like that you can curl or wget them without mucking about with certs and that you can view them using anything and everything vaguely browsery ever made. I feel moving to HTTPS subtracts value, at least to me, and I'm the owner.
Not to get all grouchy old geezer, but I don't feel every single public open simple textual website must be encrypted. Where am I wrong / what am I missing? (While understanding there's a mathematical world of difference between statements "Most / 99% of websites should be encrypted!" and "All / 100% of websites should be encrypted!" :)