[HN Gopher] Supporting Let's Encrypt, the nonprofit making HTTPS...
___________________________________________________________________
Supporting Let's Encrypt, the nonprofit making HTTPS free for all
Author : robin_reala
Score : 92 points
Date : 2021-06-14 19:29 UTC (3 hours ago)
(HTM) web link (blog.1password.com)
(TXT) w3m dump (blog.1password.com)
| joshuajill wrote:
| 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.
| merb wrote:
| 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.)
| Animats wrote:
| 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...
| metastart wrote:
| 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.
| NikolaNovak wrote:
| Love Let's Encrypt, Like 1password, support/use them both.
|
| 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!" :)
| JoshTriplett wrote:
| 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.
| jorl17 wrote:
| 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.
| [deleted]
| tw04 wrote:
| 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.
| dvfjsdhgfv wrote:
| 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.
| kelnos wrote:
| > _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.
| merb wrote:
| you can publish a sha256 hash for every site/resource. (just
| kidding of course)
| Klathmon wrote:
| 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.
| raspyberr wrote:
| From what I understand, one of the main issues with HTTP is
| that anyone in the middle can just change the content.
| Spivak wrote:
| 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.
| raspyberr wrote:
| Doesn't DoH/DoT centralise a decentralised protocol though?
| DoH is great but then you just get Cloudflare knowing all
| the DNS calls.
| Spivak wrote:
| 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.
| gsich wrote:
| 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.
| MaxBarraclough wrote:
| 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 )
| schoen wrote:
| > 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.)
| upofadown wrote:
| >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.
| xahrepap wrote:
| 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.
| gsich wrote:
| "you" and clients connecting to your server might be
| different entities.
| eliaspro wrote:
| 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/
| tialaramex wrote:
| 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.
| dvfjsdhgfv wrote:
| > 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.
| rezonant wrote:
| 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.
| fnml wrote:
| 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.
| vegardx wrote:
| 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.
| schoen wrote:
| 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.
| ArchOversight wrote:
| > 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.
| gsich wrote:
| >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.
| bo0tzz wrote:
| 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.
| t0mbstone wrote:
| 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.
| shard wrote:
| 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 it subverts the purpose of your site and
| lowers the value and trustworthiness of your site to your
| visitors.
| dvfjsdhgfv wrote:
| 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.
| bombcar wrote:
| 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.
| jorl17 wrote:
| > 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.
| cpach wrote:
| 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
| t0mbstone wrote:
| 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.
| Spivak wrote:
| 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.
| gsich wrote:
| Breached as in someone else has control over the server.
| cpach wrote:
| If you can hijack the connection (i.e. MITM) you don't
| need to control the server in order to compromise the
| integrity of the information.
| gsich wrote:
| No it doesn't. Having HTTP does not magically open the
| server.
| haswell wrote:
| It does not have to magically open the server to open an
| attack vector against the site by other means, e.g. MITM on
| an open WiFi access point. Other comments in this thread
| discuss this in more depth so I'm not elaborating here.
| anton96 wrote:
| 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.
| sofixa wrote:
| > 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).
___________________________________________________________________
(page generated 2021-06-14 23:01 UTC)