13 ms·

Everyone who adds "certbot is EZ" comments: it makes you rely on a service. This is the very problem of certificates, because self-signed was never trusted and

• duncan_bayne 6y ago
  > elf-signed was never trusted I think the main reason is that they're on the whole pretty racist towards dwarves.
  • gerikson 6y ago
    Also the security of the Doors of Durin was basically plaintext.
• mschuster91 6y ago
  > This is the very problem of certificates, because self-signed was never trusted and is not an option. What I don't get, with DNSSEC getting rolled out more and more, why can't every site operator simply stick the fingerprint of their HTTPS cert in DNS and have DNSSEC take care of the trust chain?
  • pmlnr 6y ago
    Could you please point to a tutorial/howto on this? EDIT: why on earth was this question downvoted? It was genuine, I honestly don't know how to do it.
    • mschuster91 6y ago
      In theory there is the CERT DNS record type that could be used, but no OS/lib uses it unfortunately as prior to DNSSEC there was no way to prevent the CERT record from being manipulated/intercepted :/
  • josteink 6y ago
    > What I don't get, with DNSSEC getting rolled out more and more, why can't every site operator simply stick the fingerprint of their HTTPS cert in DNS and have DNSSEC take care of the trust chain? This question is extremely relevant given how DNS-based authentication is the preferred way to authenticate with letsencrypt. If DNS is good enough for letsencrypt to validate you and give you a cert, why can't DNS be good enough for the browser alone, without needing to rely on some third party service? Letsencrypt has certainly made HTTPS easier in practice, but we really need to get rid of the whole CA-model entirely.
    • sarakayakomzin 6y ago
      >Letsencrypt has certainly made HTTPS easier in practice, but we really need to get rid of the whole CA-model entirely. solve the root trust problem and claim your nobel prize.
    • moray 6y ago
      A DKIM like service? For emails I find it very convenient, publish your public key with DNS and sign outgoing emails, outgoing emails are now "certified" coming from your server and the recipient can easily verify it, no CAs involved.
    • mytailorisrich 6y ago
      What Letsencrypt does (and all other providers of certificates to end users do) is verify that you control the domain you are requesting a certificate for. That's well and good, but who are those Letsencrypt guys, anyway? That's why there is a chain of trust and Certificate Authorities. You, and your browser, cannot know everyone out there so you pick a few 'authorities' that are well-known and deemed serious enough to be trusted and go from there. DNSSEC operates on the same principle of a chain of trust from root.
      • josteink 6y ago
        > What Letsencrypt does Letsencrypt is run by Mozilla. So lets instead make that: > What Mozilla does ... is that you control the domain you are requesting a certificate for. So Mozilla trusts me based on me controlling the DNS of my domain, and can issue me a security-token which Mozilla's browser (and other browsers) then can trust. Note: It does not trust me or verify me to be non-malicious, honest or have good intentions of any kind. It merely verifies that I control the DNS of the domain I request a certificate for. That's it. That is all. So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS, thus validating that the site-operator is indeed in control of the DNS of his domain? It will be exactly the same validation, except now we don't have to rely on a third-party service to do that for us. And then the web can finally be autonomous and decentralized again.
  • ameliaquining 6y ago
    There are a bunch of reasons why this doesn't work, but first among them is this: This would require browsers to make DNSSEC queries, and if those queries were blocked or otherwise failed, the browser would have to fail closed and present a certificate error. (The alternative, failing open and allowing users to visit a site if the browser doesn't get a response to the DNSSEC query, would be completely insecure, because the whole point of HTTPS is to defend against MITM attacks, and an MITM could simply block all DNSSEC traffic.) This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web. There are also a lot of other objections to it, including that it's too centralized (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=author%3Atptacek%20DNSSEC&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), but that's the basic reason why it can't be deployed.
    • josteink 6y ago
      > This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web. Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), despite almost the exact same reasons holding up with middle-boxes, proxies and the like. Now that there is an alternate, much simpler HTTPS-solution everyone is "oh noes that would break corporate environments". What's different this time around? Why is breaking things bad this time? If we could just sit down, and all agree that the only reason we "need" HTTPS everywhere is because running JavaScript in a browser represents a security-issue, the quicker we can start solving the real problem: JavaScript as a default-permission. The quicker we can phase that out from web-pages (which honestly more often than not, simply represents documents), the better.
      • acdha 6y ago
        > Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), This misunderstanding is where your argument went off the rails: people wanted HTTPS because they are sending data over networks which aren’t perfectly trustworthy. Starting in the late 1990s there was string consumer demand to feel safe entering credit cards and other personal information even if the site used no JavaScript - our household-name clients expected it even if they only used JS for mouseover effects. That was before WiFi became common, too, and people realized the risks of letting everyone at Starbucks see their information. DNSSEC has no equivalent because it took so long to be adopted that it offers no meaningful user benefit over HTTPS, and it’d need to be a substantial win to balance out the poor user experience and implementation challenges.
  • AndyMcConachie 6y ago
    What you're talking about is DANE. RFC 6698 https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... I wrote a short explanation of how it works a while back. https://www.metafarce.com/adventures-in-dane.html https://www.metafarce.com/adventures-in-dane.html The short answer is that DANE has been seeing deployment success for SMTP, but has yet to see much deployment success for HTTPS. https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/
    • AndyMcConachie 6y ago
      I'm one of the few weirdos that actually validates DANE for HTTPS using some software I wrote called Danish. Once in Python https://github.com/smutt/danish https://github.com/smutt/danish And again in Rust. https://github.com/smutt/danish-rust https://github.com/smutt/danish-rust An old explanation can be found here. https://www.middlebox-dane.org/ https://www.middlebox-dane.org/ Both middlebox-dane.org and metafarce.com have DNS TLSA records that match their certificate from Let's Encrypt. You can do this, but almost no one is. There is some pickup in The Netherlands where I live. For example, www.digid.nl has delpoyed DANE for HTTPS.
    • jlgaddis 6y ago
      > ... DANE has been seeing deployment success for SMTP, ... Since "DANE for e-mail" is still relatively new / obscure, for the uninitiated, RFC7672 [0] describes "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", which requires DNSSEC -- and, as a result, comes with all of its associated disadvantages / trade-offs. An alternative, more recent method of providing authenticated and encrypted delivery of e-mail is described in RFC8461 [1], "SMTP MTA Strict Transport Security (MTA-STS)", which uses DNS and HTTPS -- and, thus, relies on CAs / PKIX. MTA-STS doesn't require DNSSEC but it is then susceptible to "malicious downgrades". Although we're not going to see all e-mail being encrypted in transit anytime soon (if we ever do), it's good to know that there are folks working on solutions, including at some of the largest e-mail providers. --- [0]: https://tools.ietf.org/html/rfc7672 https://tools.ietf.org/html/rfc7672 [1]: https://tools.ietf.org/html/rfc8461 https://tools.ietf.org/html/rfc8461
• ultim8k 6y ago
  So long story short, today's internet is all about big corps. And there are always T&Cs. AKA we didn't like that article on your account, we kill all your services and deactivate your account.
• rakoo 6y ago
  On the other hand HTTP was supposed to allow everyone to author and distribute content, or perhaps only to some people. Much like any protocol, issues start to arise when it starts seeing adoption: credentials mustn't be divulged to anyone on the network, a client must be sure the content is genuinely from who authored it and no one else, middlewares are funking up with content on the way, etc... HTTP alone doesn't serve its initial purpose at the large scale. That's like having a process for building homes out of dirt and hay, a totally viable way of doing your own house today, but it definitely won't be enough to house the 10 billion people of tomorrow. The real alternative to provide what HTTP once wanted to provide, if not HTTPS (because of its reliance on points of contention), is in the decentralized web: dat, zeronet, ipfs ?
  • kragen 6y ago
    HTTP originally didn't have credentials. If your site had a WWW server installed, you just put a file in your ~/public_html/ directory, and there it was on the WWW. Like, you could literally put HTML on the web by typing two lines of text into your shell: mkdir ~/public_html/ echo 'My Samoyed is <b>really</b> hairy.' > ~/public_html/index.html There were no headers and thus nowhere to put credentials in an HTTP request. We trusted the network because we didn't give root to people we didn't trust. If the people steering the dominant browser projects think that allowing everyone to author and distribute creative work is important, they'll keep supporting HTTP, and they might also direct effort to supporting dat, zeronet, ipfs, onion sites, and so on. If they don't think that's important, they probably won't do any of those things, even though, yes, the tradeoffs are a little different. Since most of them are at Apple and Google, I think the iOS App Store and the Google Play Store probably represent the future of the web. I think that sucks but I don't know how to stop it. As for adobe, it's pretty labor-intensive and slow as a way of doing your own house, and it doesn't work that well in very damp climates like Seattle. But there's no difficulty at all in scaling it up to 10 billion people, and indeed with compressed-earth brick presses, it might work better with modern industrial machinery than with the traditional North African craft processes that we now use all over the New World. There's plenty of suitable dirt and hay out there.
    • 6y ago
• hmwhy 6y ago
  I don't necessarily disagree with what you said, but for every person who pays attention to the difference between HTTP and HTTPS, and understands what it means, whenever visiting a website, there are probably many more who don't. Until someone who is trusted, technically capable, and has a better and sustainable solution that optimises collective good, I'm not sure that the current situation we are in is really that bad.
• p49k 6y ago
  This would be a stronger point if the most popular provider of the service you would have to rely on wasn't a non-profit who provides their services for free and makes tools that are extremely easy to use and understand. It's a pretty fantastic outcome given the need for encryption in modern times. Let's also not forget that having a HTTP website relies on other services that are maintained by others as well; this isn't going from "full independence" to dependence, it's going from N dependencies to N+1.
• kop316 6y ago
  > self-signed was never trusted The whole problem of a self-signed cert is unless you have a priori knowledge of the cert somehow, it then is trivial to MITM a self-signed cert. That is why it was never trusted. That is the point of a signed cert, you are inherently trusting a third party to tell you the cert a website is giving you is good. It does bring up an idea of making an individual a CA (i.e. you know someone's PGP key and that PGP key signs a cert, and that is a way to trust it). But you still fallback on the same issues with PGP email, you ultimately need someway of trusting it in the first place.
  • pmlnr 6y ago
    Self signed is more, than enough for the same purpose certbot exists: to have encrypted communication.
    • pilsetnieks 6y ago
      That is only one, the most basic purpose and the only that self-signed certificates can do. LE and other certificate authorities* at least prove that your data wasn't tampered with in transit, or wasn't decrypted, read and reencrypted without any way for you to find out. * as long as you trust those authorities
      • deleted 6y ago
        [deleted]
    • kop316 6y ago
      How do you verify the cert then? If you can't verify the cert, you have no way to know it is not being man in the middled.
      • fortran77 6y ago
        How about putting some hash of the self-signed cert in a DNS TXT field?
• Etheryte 6y ago
  I want to believe that somewhere out there, Orlando Bloom is signing everyone's certs with his usual ambiguous Legolas expressions. That typo was such a happy little accident.
  • dredmorbius 6y ago
    Elf-signed certificates should absolutely be A Thing.
• dilandau 6y ago
  Completely agree. HTTP isn't affected by any of the politicking going on in Mozilla, but it certainly affects users. Purporting to be a user-agent, Mozilla (and to a degree the other big browsers) have taken away a few of the sharp objects lying around, to extend protection to less savvy users. When I think about my old grandma or my oblivious inlaws downloading "free games" and constantly getting scammed or infected with viruses, this whole HTTPS thing seems awfully ridiculous. The internet is full of websites that will grift you if you aren't careful. I think the other part of it is also that FF is trying to position itself as the browser for security-conscious users. Hence the aggressive blocking... whether it works or not is another question.
• fortran77 6y ago
  Certbot is not that easy. Several times my auto-renew scripts have failed because some API change makes me need to update my auto-renew script.
  • folkhack 6y ago
    I just went through this with my GitLab and pages for self-hosting. Miserable. Certbot is not a silver bullet and is easy until it's not.
• kevstev 6y ago
  Its a hoop to jump through to get things to work- and an external dependency. I mean I remember the days when I first got a cable modem, I could just start up IIS or Apache and immediately have a web page on the internet. With a little hackery with dynamic DNS, it could be a "proper" webpage with a domain name. There are a lot of websites out there that just want to serve some static data or host a blog, and https IMHO adds nothing but a layer of complexity for no benefit.
• tenebrisalietum 6y ago
  Self signed just means you have to create and distribute a CA cert, and your platform has to support adding CA certs. AFAIK Chrome, Firefox, IE, Edge, and mobile browsers on Android and iOS can do this. You generate a CA cert using a utility like xca and then create client certs signed by it. You can use signing requests if you don't want to know the password that protects the certs (in my scenario, I was fine with that). You then export your client certs, with your CA cert included, and coordinate with people who need access to install the cert on their browser or OS. Your users will get prompted to trust a new CA (as they should). Combine with a webserver that supports routing requests based on certificate status, like nginx, and it's pretty neat. You can allow access to only those who have a cert signed by your CA. I did this for the longest time before letsencrypt was a thing, and if letsencrypt goes away, I'll go back to it.
• geonnave 6y ago
  Indeed, the main problem of trust is the third party and agreement. The DID and VC standards have an interesting approach. Use self-signed public keys, and third-party-signed credentials. To prevent MITM use credentials, to encrypt channel use the keys. The agreement part, however, remains difficult because the protocols are always evolving. Maybe in a few years we'll get it solved, just like Bitcoin solved double-spending without centralization?
• crazypython 6y ago
  Why can't browsers allow self-signed certificates as long as it is signed by a private key on a DNS record with DNSSEC enabled?
  • syntheticcdo 6y ago
    Sounds like DANE.