10 ms·

Progress Towards 100% HTTPS, June 2016

220 points by dankohn1 10y ago

projectramo 10y ago
Is there any work being done on being able to easily switch out standards? That way when https is found to lack some feature, we can easily upgrade to httpz almost immediately?
- p4lindromica 10y ago
  The s in https just means secure. It has evolved from SSL to TLS with various versions of each. 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.
- sp332 10y ago
  The situation is not ideal. But the consensus among browser makers is that the previously-relevant standards bodies move too slowly. They can implement new transport features independently (like Chrome did with SPDY and QUIC). But the downside is that fragmentation is more likely, as most browsers implemented SPDY's features in HTTP/2 but only Opera has added QUIC.
- vtlynch 10y ago
  This will likely never be the case due to how HTTPS actually works. As someone else stated, HTTPs is HTTP + TLS. 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).
  - profmonocle 10y ago
    Plus, even if we did decide to fully replace TLS, nothing would necessarily need to happen with certificates. We call them "SSL certificates", but the certificate standard - X.509 - actually predates SSLv1 by several years. A TLS alternative/replacement could adopt the X.509 standard as its certificate format and automatically work with the existing CA system.
criddell 10y ago
Just at the entire world is going HTTPS, my faith in the system is seriously waning. When Symantec bought Blue Coat, it made me start to think about how fragile this is. How long before Symantec gets an NSL demanding an appliance that can mint bogus certs on the fly for dropbox.com, facebook.com, twitter.com, etc...? How effective is something like certificate pinning against fraudulent certs?
- 5ilv3r 10y ago
  I don't think they would be considered fraudulent at all, and in fact I'm pretty sure that's the "safety valve" built into the system and why public encryption is now being encouraged. I share your tinfoil hatted feelings wholeheartedly.
  - schoen 10y ago
    > I don't think they would be considered fraudulent at all Er, by whom?
    - 5ilv3r 10y ago
      Well, they would be as technically valid as any other updated cert, and they would not violate any laws since a judge somewhere would have rubber stamped it, so I just don't think that word fraudulent could apply in any actionable sense. Morally wrong, sure, but you know, politicians and law enforcement...
      - pfg 10y ago
        Fraudulent is not usually a term that's referring to legal assessments when talking about the CA system. Various browsers and root programs are (to keep the comparison) both the executive and judiciary branch of the CA system, and if certificates are issued in a way that's not allowed in those policies (which would certainly be the case in this scenario), it would be considered fraudulent and could lead to root removal.
  - pfg 10y ago
Abundnce10 10y ago
Let’s Encrypt has issued more than 5 million certificates in total since we launched to the general public on December 3, 2015. Approximately 3.8 million of those are active, meaning unexpired and unrevoked. Our active certificates cover more than 7 million unique domains. How can you cover 7 million unique domains if you've only issued 5 million certificates?
- deleted 10y ago
  [deleted]
- waterphone 10y ago
  One certificate can be for more than one domain.
  - altano 10y ago
    For example, a single cert can serve www.example.com as well as example.com
    - gummiruessel 10y ago
      That is true, but in this case I think Let's Encrypt and also parent to your comment mean different domains as in e.g. one certificate to cover all three of example.com, example.net and example.org.
      - 5ilv3r 10y ago
        The same mechanism in cert generation provides that functionality. Hostnames are hostnames. SAN certs just take a list of them.
- schoen 10y ago
  A certificate can cover many domains thanks to the subjectAltName extension.
zzzcpan 10y ago
Is it still problematic to issue lots of certs for lots of subdomains? I mean, still no wildcard certs and crazy rate limits, that disallow issuing 1000s of certs per day for user-generated subdomains?
- Freaky 10y ago
  Yep. You can get 20 different certificates per domain per week, with up to 100 names on each. https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
- tracker1 10y ago
  If you're generating that many subdomains (and you control the subdomains), it's probably worth investing in a traditional wildcard cert. Though, it would be nice if the likes of dyndns names were given exception, since they are effectively second level tld's.
  - mieko 10y ago
    LE uses the Public Suffix List to decide what's a "domain". Their really-low rate limits have caused a flood of applications which are overwhelming the PSL's maintainers. https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns-support/883/16 https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns...
- perlgeek 10y ago
  Though if you are a hosting provider for example, I'm sure you could try to negotiate a deal with let's encrypt for more tolerant rate limits for a bit of sponsoring.
  - jaas 10y ago
    We do, in limited cases for large providers (we can only handle so many requests), adjust rate limits. Such adjustments are never dependent on sponsorship, though sponsorship is nice.
- 10y ago
simbalion 10y ago
This is extremely exciting. I've been supporting these folks since the beta. It's great for offering free SSL to clients.
5ilv3r 10y ago
I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. 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.
- toomanythings2 10y ago
  And when we visit your site for the first time, having never heard of you before, why should we trust you? 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.
  - 5ilv3r 10y ago
    Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. :) 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.
    - ademarre 10y ago
      > Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. 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.
      - 5ilv3r 10y ago
        I would argue strongly that such users do not have those abilities even with https. A valid cert is a valid cert. My supporting point would be the major browser vendors recent backpedal on throwing mixed-content errors, demonstrating that a smooth ride for the user is far more important than safety to them. 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.
rogerbinns 10y ago
I keep hoping they will help address non-Internet TLS. For example if you run a HTPC, fridge, printer, device controller or anything similar on your LAN and want to talk to it over the same LAN using TLS. Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique. 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-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- Retr0spectrum 10y ago
  For local traffic, why do you need a public certificate authority?
  - maratd 10y ago
    Because some devices and browsers have difficulty determining if they're talking to something on the local network or not. And they don't try to guess. So if your router requires you to connect via HTTPS, which is a good idea, have fun clicking past a nasty warning and then have nasty icons everywhere telling you that you're not secure. 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.
    - Franciscouzo 10y ago
      That's not a problem of browsers having a difficulty determining if they're talking to something on a local network or not, just because you're in a local network doesn't means you can't be victim of a MiTM.
  - IgorPartola 10y ago
    Because every device and program uses more or less the same list of trusted root certs. Yes, you can install your own root cert and run your own CA for stuff like this, but it's a huge pain in the ass to actually install the cert on all your devices. Sure, you can put that cert in your Chrome trust store. But what about Firefox, Safari, IE/Edge? What about your iPhone with Safari and Chrome? What about curl/telnet? What about your daughter's tablet, your son's gaming rig, your wife's e-reader? It's all just so much work. Businesses that have in-house IT departments can get away with it because they provision hundreds/thousands of identical installs of the same software. You don't have that in your house or small office.
g8oz 10y ago
Blackberry 10 browser refuses to recognize Lets Encrypt certs :(
Animats 10y ago
I see this as security theater. Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point. Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length. 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.
- mholt 10y ago
  Sorry, but your comment is literally all wrong.
  - rsync 10y ago
    Have you ever built toolchains on top of parsing web resources with unix primitives ? 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.
    - pfg 10y ago
      mholt is the lead developer of Caddy[1], so it's probably safe to assume that he knows a bit about this. 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. [1]: https://caddyserver.com/ https://caddyserver.com/
    - mholt 10y ago
      This has nothing to do with complexity or tooling. 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] [1]: https://gist.github.com/ryankearney/4146814 https://gist.github.com/ryankearney/4146814
arca_vorago 10y ago
Is there any alternative to ssl and tls out there? Sshttp anyone?
- nisa 10y ago
  Tor Onions are technically an alternative. You access the hash of the public key? and you are only able to put up that URI if you have control over the private key. I guess something similar based on hashing and public key cryptography might be possible outside of Tor but it's not exactly user friendly to begin with.
yeukhon 10y ago
My understanding is for intranet, you could use Let's Encrypt. For example, if I own .foo.com, and i want my intranet to be .internal.foo.com I need to make *.internal.foo.com in the DNS in order to verify I own .internal.foo.com, correct? But then doesn't that expose my 'internal' network? Hope there is a different way to solve this problem.
- pfg 10y ago
  You don't need to "open up" your internal network (the ownership validation can happen via DNS), but the hostname would be public through Certificate Transparency. 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.
cdolan92 10y ago
This is great, I use LetsEncrypt for my company. however, the graph is a little misleading. Lets look closer: 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.
rsync 10y ago
Am I the only person that is wary of 100% https ? 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...
- icebraining 10y ago
  Just as you can use "nc" for an HTTP resource, you can use "openssl s_client" or "ncat --ssl" (from the nmap project) or "socat" to manipulate an HTTPS resource using the same unix primitives. Which truckload of dependencies does this require? The Debian package for OpenSSL only depends on libc. 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.
vizza 10y ago
Add monitoring for cert expiration and validity: https://letsmonitor.org https://letsmonitor.org

220 points by dankohn1 10y ago

Is there any work being done on being able to easily switch out standards? That way when https is found to lack some feature, we can easily upgrade to httpz almost immediately?

p4lindromica 10y ago
The s in https just means secure. It has evolved from SSL to TLS with various versions of each. 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.
sp332 10y ago
The situation is not ideal. But the consensus among browser makers is that the previously-relevant standards bodies move too slowly. They can implement new transport features independently (like Chrome did with SPDY and QUIC). But the downside is that fragmentation is more likely, as most browsers implemented SPDY's features in HTTP/2 but only Opera has added QUIC.
vtlynch 10y ago
This will likely never be the case due to how HTTPS actually works. As someone else stated, HTTPs is HTTP + TLS. 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).
- profmonocle 10y ago
  Plus, even if we did decide to fully replace TLS, nothing would necessarily need to happen with certificates. We call them "SSL certificates", but the certificate standard - X.509 - actually predates SSLv1 by several years. A TLS alternative/replacement could adopt the X.509 standard as its certificate format and automatically work with the existing CA system.

criddell 10y ago

Just at the entire world is going HTTPS, my faith in the system is seriously waning. When Symantec bought Blue Coat, it made me start to think about how fragile this is. How long before Symantec gets an NSL demanding an appliance that can mint bogus certs on the fly for dropbox.com, facebook.com, twitter.com, etc...? How effective is something like certificate pinning against fraudulent certs?

5ilv3r 10y ago
I don't think they would be considered fraudulent at all, and in fact I'm pretty sure that's the "safety valve" built into the system and why public encryption is now being encouraged. I share your tinfoil hatted feelings wholeheartedly.
- schoen 10y ago
  > I don't think they would be considered fraudulent at all Er, by whom?
  - 5ilv3r 10y ago
    Well, they would be as technically valid as any other updated cert, and they would not violate any laws since a judge somewhere would have rubber stamped it, so I just don't think that word fraudulent could apply in any actionable sense. Morally wrong, sure, but you know, politicians and law enforcement...
    - pfg 10y ago
      Fraudulent is not usually a term that's referring to legal assessments when talking about the CA system. Various browsers and root programs are (to keep the comparison) both the executive and judiciary branch of the CA system, and if certificates are issued in a way that's not allowed in those policies (which would certainly be the case in this scenario), it would be considered fraudulent and could lead to root removal.
- pfg 10y ago

Abundnce10 10y ago

Let’s Encrypt has issued more than 5 million certificates in total since we launched to the general public on December 3, 2015. Approximately 3.8 million of those are active, meaning unexpired and unrevoked. Our active certificates cover more than 7 million unique domains. How can you cover 7 million unique domains if you've only issued 5 million certificates?

deleted 10y ago
[deleted]
waterphone 10y ago
One certificate can be for more than one domain.
- altano 10y ago
  For example, a single cert can serve www.example.com as well as example.com
  - gummiruessel 10y ago
    That is true, but in this case I think Let's Encrypt and also parent to your comment mean different domains as in e.g. one certificate to cover all three of example.com, example.net and example.org.
    - 5ilv3r 10y ago
      The same mechanism in cert generation provides that functionality. Hostnames are hostnames. SAN certs just take a list of them.
schoen 10y ago
A certificate can cover many domains thanks to the subjectAltName extension.

zzzcpan 10y ago

Is it still problematic to issue lots of certs for lots of subdomains? I mean, still no wildcard certs and crazy rate limits, that disallow issuing 1000s of certs per day for user-generated subdomains?

Freaky 10y ago
Yep. You can get 20 different certificates per domain per week, with up to 100 names on each. https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
tracker1 10y ago
If you're generating that many subdomains (and you control the subdomains), it's probably worth investing in a traditional wildcard cert. Though, it would be nice if the likes of dyndns names were given exception, since they are effectively second level tld's.
- mieko 10y ago
  LE uses the Public Suffix List to decide what's a "domain". Their really-low rate limits have caused a flood of applications which are overwhelming the PSL's maintainers. https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns-support/883/16 https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns...
perlgeek 10y ago
Though if you are a hosting provider for example, I'm sure you could try to negotiate a deal with let's encrypt for more tolerant rate limits for a bit of sponsoring.
- jaas 10y ago
  We do, in limited cases for large providers (we can only handle so many requests), adjust rate limits. Such adjustments are never dependent on sponsorship, though sponsorship is nice.
10y ago

simbalion 10y ago

This is extremely exciting. I've been supporting these folks since the beta. It's great for offering free SSL to clients.

5ilv3r 10y ago

I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. 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.

toomanythings2 10y ago
And when we visit your site for the first time, having never heard of you before, why should we trust you? 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.
- 5ilv3r 10y ago
  Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. :) 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.
  - ademarre 10y ago
    > Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money. 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.
    - 5ilv3r 10y ago
      I would argue strongly that such users do not have those abilities even with https. A valid cert is a valid cert. My supporting point would be the major browser vendors recent backpedal on throwing mixed-content errors, demonstrating that a smooth ride for the user is far more important than safety to them. 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.

rogerbinns 10y ago

I keep hoping they will help address non-Internet TLS. For example if you run a HTPC, fridge, printer, device controller or anything similar on your LAN and want to talk to it over the same LAN using TLS. Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique. 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-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

Retr0spectrum 10y ago
For local traffic, why do you need a public certificate authority?
- maratd 10y ago
  Because some devices and browsers have difficulty determining if they're talking to something on the local network or not. And they don't try to guess. So if your router requires you to connect via HTTPS, which is a good idea, have fun clicking past a nasty warning and then have nasty icons everywhere telling you that you're not secure. 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.
  - Franciscouzo 10y ago
    That's not a problem of browsers having a difficulty determining if they're talking to something on a local network or not, just because you're in a local network doesn't means you can't be victim of a MiTM.
- IgorPartola 10y ago
  Because every device and program uses more or less the same list of trusted root certs. Yes, you can install your own root cert and run your own CA for stuff like this, but it's a huge pain in the ass to actually install the cert on all your devices. Sure, you can put that cert in your Chrome trust store. But what about Firefox, Safari, IE/Edge? What about your iPhone with Safari and Chrome? What about curl/telnet? What about your daughter's tablet, your son's gaming rig, your wife's e-reader? It's all just so much work. Businesses that have in-house IT departments can get away with it because they provision hundreds/thousands of identical installs of the same software. You don't have that in your house or small office.

g8oz 10y ago

Blackberry 10 browser refuses to recognize Lets Encrypt certs :(

Animats 10y ago

I see this as security theater. Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point. Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length. 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.

mholt 10y ago
Sorry, but your comment is literally all wrong.
- rsync 10y ago
  Have you ever built toolchains on top of parsing web resources with unix primitives ? 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.
  - pfg 10y ago
    mholt is the lead developer of Caddy[1], so it's probably safe to assume that he knows a bit about this. 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. [1]: https://caddyserver.com/ https://caddyserver.com/
  - mholt 10y ago
    This has nothing to do with complexity or tooling. 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] [1]: https://gist.github.com/ryankearney/4146814 https://gist.github.com/ryankearney/4146814

arca_vorago 10y ago

Is there any alternative to ssl and tls out there? Sshttp anyone?

nisa 10y ago
Tor Onions are technically an alternative. You access the hash of the public key? and you are only able to put up that URI if you have control over the private key. I guess something similar based on hashing and public key cryptography might be possible outside of Tor but it's not exactly user friendly to begin with.

yeukhon 10y ago

My understanding is for intranet, you could use Let's Encrypt. For example, if I own .foo.com, and i want my intranet to be .internal.foo.com I need to make *.internal.foo.com in the DNS in order to verify I own .internal.foo.com, correct? But then doesn't that expose my 'internal' network? Hope there is a different way to solve this problem.

pfg 10y ago
You don't need to "open up" your internal network (the ownership validation can happen via DNS), but the hostname would be public through Certificate Transparency. 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.

cdolan92 10y ago

This is great, I use LetsEncrypt for my company. however, the graph is a little misleading. Lets look closer: 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.

rsync 10y ago

Am I the only person that is wary of 100% https ? 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...

icebraining 10y ago
Just as you can use "nc" for an HTTP resource, you can use "openssl s_client" or "ncat --ssl" (from the nmap project) or "socat" to manipulate an HTTPS resource using the same unix primitives. Which truckload of dependencies does this require? The Debian package for OpenSSL only depends on libc. 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.

vizza 10y ago

Add monitoring for cert expiration and validity: https://letsmonitor.org https://letsmonitor.org