[HN Gopher] Does my site need HTTPS?
___________________________________________________________________
Does my site need HTTPS?
Author : WallyFunk
Score : 79 points
Date : 2022-01-31 17:25 UTC (5 hours ago)
(HTM) web link (doesmysiteneedhttps.com)
(TXT) w3m dump (doesmysiteneedhttps.com)
| marginalia_nu wrote:
| Eh, I really wish there would be more pushback against HTTPS.
|
| It does include a lot of problems, including the reporting of
| browsing information through non-stapled OCSP, there's still
| major MITM-problems (yes, still; for example CloudFlare is huge-
| ass MITM), and no matter what this site claims, HTTPS is
| definitely still a lot slower than HTTP, even with HTTP/2; and it
| further makes it a lot easier to hide which data is extracted
| from a computer from the user. Encryption is great if you are
| using it, but it can also very much be used against you. The
| centralization it drives also creates unpleasant attack vectors
| for snooping governments.
|
| I wish there was a way non-sensitive data could be transmitted
| plain-text, but signed with a server certificate. This solves
| many of the same problems, while avoiding many of the problems
| with HTTPS.
| mholt wrote:
| > reporting of browsing information through non-stapled OCSP
|
| This is a client bug, IMO. And sensible servers like Caddy (and
| yes, before people complain about disclosure, I made it) staple
| OCSP automatically.
|
| > here's still major MITM-problems (yes, still; for example
| CloudFlare is huge-ass MITM),
|
| But optional (and often discouraged), not required! Separate
| issue.
|
| > HTTPS is definitely still a lot slower than HTTP, even with
| HTTP/2
|
| That's just plain false across most dimensions. https://css-
| tricks.com/http2-real-world-performance-test-ana...
|
| > it further makes it a lot easier to hide which data is
| extracted from a computer from the user
|
| That's a separate issue too; don't use clients you don't trust,
| period. And some big-name clients like Chrome let you dump keys
| to inspect data transfers locally.
|
| > I wish there was a way non-sensitive data could be
| transmitted plain-text, but signed with a server certificate.
|
| TLS supports a "NULL" cipher in certain cipher suites for
| signed-only transmissions, but mainstream server and client
| support are limited (for good reasons).
| mhitza wrote:
| > That's just plain false across most dimensions.
| https://css-tricks.com/http2-real-world-performance-test-
| ana...
|
| I always feel like any performance claims are nowhere near my
| real life experience, not even when talking about synthetic
| benchmarks.
|
| For example I recently set up an Apache server that returned
| a 304 response, on an AWS t3.micro instance and with the
| Apache Benchmark tool I got around 3.5k[0] requests per
| second. Once I've enabled HTTPS that fell to around 500
| requests per second.
|
| From what I've read at the time (because I was aware of the
| general consensus that they should have comparable
| performance), there is some type of underlying hardware
| feature the TLS decryption/encryption routine can use to
| speed things up, but it's only available in AWS in m3 type
| instances and above. Read it from a Mozilla (I think)
| article, that I couldn't find again right now.
|
| [0] that 3.5k/500 rps might be higher for you because I used
| maxminddb IP mapping on each requests which I'm sure adds
| some considerable factor to the rps.
| SahAssar wrote:
| If all your server does is respond with a single small no-
| body response, then yes http will be much quicker. If you
| do a somewhat normal page (even something considered small
| by current standards like 5-10 resources each being 10-ish
| kb) it will be a wash or http2 will be better.
| mysterydip wrote:
| Is there a layperson explanation for why https is faster than
| http? On the surface, "read file-> send to client" seems like
| less steps than "read file -> encrypt -> send to client"
| jedberg wrote:
| http/2 is faster (for various technical reasons but
| basically it sends multiple things at once better than old
| http) and http/2 requires security.
|
| So technically http/2 is faster, but it is only possible
| with https.
| SahAssar wrote:
| > So technically http/2 is faster, but it is only
| possible with https.
|
| Because of arbitrary client restrictions. http/2 can be
| unencrypted, and would be faster unencrypted than
| encrypted. It's just that all servers/clients decided to
| not implement the optional unencrypted mode.
|
| I'm not arguing either way, but technically it is
| possible to do it without https.
| mholt wrote:
| "Faster" is ambiguous, and there are a lot of factors
| involved. HTTPS isn't just "add encryption", it's also "do
| more at once and don't block as much" because HTTP/2 (a
| faster version of HTTP) only uses HTTPS in practice.
|
| You can discuss "HTTPS performance" in a purist way that
| makes it look slower than plain HTTP, but in practice (the
| only way that matters) HTTPS is faster than HTTP.
| singlow wrote:
| I didn't see any claim that https is faster. If you
| benchmark https on a path where encryption is the only
| significant work being done, and on hardware that does not
| have encryption acceleration, then it will appear to be a
| lot slower. However, in real world applications the https
| encryption is usually accelerated by a dedicated processor
| feature, and the other work being done for a request is
| going to make the encryption time irrelevant. If you are
| serving static files over http, on a machine with an old
| cpu, with enough volume to saturate your cpu on http, then
| https will slow it down significantly. But typically, any
| server doing that will have 100x more capacity than it
| needs anyway.
| marginalia_nu wrote:
| > This is a client bug, IMO. And sensible servers like Caddy
| (and yes, before people complain about disclosure, I made it)
| staple OCSP automatically.
|
| As a client I don't get to choose how the servers interact
| with are configured.
|
| > But optional (and often discouraged), not required.
| Separate issue!
|
| Not at all a separate issue. The issue is the absolute
| fantasy that HTTPS makes your connection secure.
|
| > Don't use clients you don't trust, period. And some big-
| name clients like Chrome let you dump keys to inspect data
| transfers locally.
|
| Are you really telling me I have to implement every piece of
| software I want to run myself from scratch, write custom
| firmware for my processor, for my router, then sit down and
| create a custom ROM with a custom operating system for my
| phone?
| SahAssar wrote:
| > Not at all a separate issue. The issue is the absolute
| fantasy that HTTPS makes your connection secure.
|
| HTTPS is reasonably secure if the person in control of the
| domain is making sure it is reasonably secure. Setting up
| your whole domain to be MITM is not that.
|
| Your connection to whatever place the person in control of
| the domain has delegated your connection to is reasonably
| secure.
| hdjjhhvvhga wrote:
| > The issue is the absolute fantasy that HTTPS makes your
| connection secure.
|
| Well, this is a kind of compromise. It is similar with
| COVID-19 vaccines: even though they don't prevent
| transmission, hospitalization and death, they do reduce
| them (at least the last two).
|
| Even though HTTPS can not offer a very high protection
| level, together with accompanying technologies they do make
| certain attacks more problematic - especially sniffing. So
| for _most_ intents and purposes, HTTPS may make a
| connection more secure.
| mholt wrote:
| > As a client I don't get to choose how the servers
| interact with are configured.
|
| Clients are the ones that cause the privacy leak, not
| servers.
|
| > The issue is the absolute fantasy that HTTPS makes your
| connection secure.
|
| Oh, OK.
|
| > Are you really telling me I have to implement every piece
| of software I want to run myself from scratch, write custom
| firmware for my processor, for my router, then sit down and
| create a custom ROM with a custom operating system for my
| phone?
|
| If you don't trust them, then yes. Nothing new here though.
| d4mi3n wrote:
| > I wish there was a way non-sensitive data could be
| transmitted plain-text, but signed with a server certificate.
| This solves many of the same problems, while avoiding many of
| the problems with HTTPS.
|
| Isn't this, more-or-less, HTTPS? I think you'd end up with
| something very similar as you'd likely need to solve the same
| problems HTTPS attempts to solve:
|
| 1. How do you know the authenticity of a message? You need some
| out of band channel of communication or trusted intermediary to
| verify anything you receive (e.g. a certifying authority)
|
| 2. How do you know when somebody's signature has changed?
|
| 3. When does a message expire? Can somebody replay a previous
| valid response?
|
| And stepping past a few of these implementation issues; how
| much overhead is HTTPS really? TLS is definitely a chatty
| protocol, but as I understand things that has more to do with
| TCP and the complexity of the CA system than the encryption
| itself.
|
| I like your idea of a faster HTTP variant that only guarantee
| message integrity rather than secrecy, but I myself can't see
| how you'd get there without implementing a lot of the things
| that makes HTTPS slower than vanilla HTTP.
| Spivak wrote:
| You don't actually have to use OCSP if you're willing to accept
| that you might erroneously trust a revoked certificate. Having
| short cert lifetimes helps reduce the need for this unless
| you're really worried about security. There is no MITMing TLS
| that isn't explicitly allowed by the client (proxy) or server
| (reverse proxy). Nothing about TLS makes hiding data from the
| user any easier or harder. If you really wanted to hide your
| data extraction you would just encrypt the payload and then
| send it in "plain text."
|
| Centralization is the point where I agree with you, I would
| love to see browsers support a scheme where certs can be TOFU
| with a private CA.
| fireflymetavrse wrote:
| >"I can't afford a certificate."
|
| >They're free.
|
| May be free but is it still applicable on hosting providers like
| Godaddy?
| marcosdumay wrote:
| > hosting providers like Godaddy
|
| You mean ones that will try to exploit and defraud you on every
| opportunity? Probably not.
|
| If you mean hosting providers in general, yes, they'll usually
| handle a Let's Encrypt certificate for you for free.
| giantrobot wrote:
| I've had DreamHost forever and Let's Encrypt is literally a
| check box on a domain. They may even support others like
| ZeroSSL but I haven't bothered to look because I don't care.
| I take the savings on paying for SSL and donate it to the EFF
| and Let's Encrypt.
| dioxide wrote:
| Yes, absolutely.
| chme wrote:
| I guess public linux distribution repo mirrors can still be http,
| if you are fine with leaking which packages you are installing.
|
| The packages themselves are signed and checked locally before
| installing them, so MITM shouldn't be possible. If your local
| trust is broken, then you lost already.
|
| And you can easily setup caching proxies for the repos, without
| requiring to setup your own CA.
| Anunayj wrote:
| Though https still has the privacy advantage, if I update over
| http, my ISP knows I downloaded the tor package, this
| information won't be leaked over https. and since it's minimal
| trouble to set up https, I think it's fine
| Xylakant wrote:
| Note that deb packages are not usually signed unless something
| major changed in the last 5 years or so. The repository
| metadata is signed and contains a checksum of all packages.
| It's all safe as long as you install from a repo, but
| installing a deb package directly doesn't usually do signature
| checks. See https://www.debian.org/doc/manuals/securing-debian-
| manual/de...
|
| AFAIR there are options to sign packages themselves, but
| there's at least two competing incompatible signing schemes.
|
| rpm packages carry a signature in the package itself.
| beardog wrote:
| While its not common enough to matter much, there have been
| cases of apt vulns (DSA-4371-1) which would give anyone who can
| exploit it with a MITM root access.
|
| One example of where this could lead to a wide spread attack is
| distros like whonix.org which update over Tor. They mitigate
| this with https/.onion package servers.
|
| Theres also the smaller problem of package-set fingerprinting
| like you said.
| solarkraft wrote:
| > if you are fine with leaking which packages you are
| installing
|
| I'd rather not ...
| endofreach wrote:
| Yes.
| arpa wrote:
| But it runs in my LAN.
| Zekio wrote:
| you can use lets encrypt certificates on your lan using DNS
| verification
| arpa wrote:
| effort / gain ratio is crap tho. Especially assuming IPv4 and
| reasonable firewalling.
| Zekio wrote:
| effort is basically none, aside from getting an API key
| from Cloudflare(could be any provider really) and then
| downloading the version of Caddy that includes supports
| Cloudflare DNS verification
|
| in terms of gains you get the benefit of easy to remember
| names, and you don't share everything in plaintext which is
| becoming more and more important as we get more and more
| devices on our LANs
| defanor wrote:
| FWIW, the setup can be simpler and more portable without
| a specialized HTTP server and with a standardized
| protocol (RFC 2136): just certbot and its
| python3-certbot-dns-rfc2136.
| pixl97 wrote:
| "It's me, UR hax0r in your I0T, steelin your unencrypted
| packets"
| eric_b wrote:
| For everyone here saying "Just use Let's Encrypt" - well, they've
| had some security issues over the last couple of years. Most
| recently [1]. They revoke certs and change challenges seemingly
| on a whim. I've had a number of fires to put out in the past 12
| months because of LE.
|
| Also, good luck using LE in a web farm type environment "easily".
| Given the challenge limits there's usually a fair bit of plumbing
| required to get multiple servers on the same domain with the same
| certificates. It's anything but "just works".
|
| [1] https://www.bleepingcomputer.com/news/security/lets-
| encrypt-...
| dvdkon wrote:
| It works for a whole lot of people and usecases. It's not
| perfect, the whole CA system is pretty terrible, but just as
| the site says, it's what we've got. The kinds of sites which
| don't have HTTPS to this day likely don't need high-
| availability. It's sad LE doesn't work well for your usecases,
| but you shouldn't dissuade people from using it in the many
| cases where it really does "just work".
| mholt wrote:
| The instance you linked to wasn't a security issue, it was a
| compliance issue: https://news.ycombinator.com/item?id=30085948
|
| > _Head of Let's Encrypt here. This is a compliance issue,
| there is no security or validation integrity risk._
| zaitanz wrote:
| If you have cronjobs/scheduled tasks running every day to try
| and renew the certificate (as recommended), then you'd not have
| any issues with them revoking. Any certificates that are going
| to be revoked will be renewed before then; this is how LE
| works. They gave 5 days notice, and during that 5 day period
| any certificates that will revoked would be renewed.
|
| For multiple servers running the same domain, you can configure
| them all the same and they will get certificates fine. If
| required, they will get a new certificate from LE; if this is
| not required then LE will provide the current certificate to
| the server. There maybe a short time where the actual
| certificate on two servers maybe different, but both would
| still be considered valid. So there really shouldn't be any
| plumbing required. (edit: This is dependent on you having a
| sensible way to load balance them. If you're just running IP
| round-robin then it's going to be difficult, but that is what
| scp and custom routes are for).
|
| I use LE for multiple domains, on multiple systems. Internal
| and external with no issue. I've even had certificates revoked
| by LE and it's never had any operational impact.
| pierrebeaucamp wrote:
| Some counter-arguments from n-gate.com:
| http://n-gate.com/software/2017/07/12/0/
| francislavoie wrote:
| This article comes off as basically victim-blaming, when it
| comes to "not my problem" if some bad actor injects ads etc.
|
| The arguments against Caddy are no longer true. Caddy runs on a
| ton of platforms, essentially any that Go can use as compile
| targets (except for plan9 for the moment because of a
| dependency of Caddy's that has a compatibility problem https://
| github.com/caddyserver/caddy/issues/3615#issuecommen...). Caddy
| also doesn't have to run as root, nor does it by default with
| our apt/yum packages.
|
| Also a passing comment essentially calling Let's Encrypt...
| with their track record at this point, I don't think that can
| be said.
|
| The rest is basically just vitriol.
| deadbunny wrote:
| That just bring to to a page with a never loading captcha on
| Android Firefox.
| ziggus wrote:
| Try pasting the link into a new browser tab. It's a redirect
| if you're coming from HN.
| kevingadd wrote:
| You have to open it in a private window
| wizzwizz4 wrote:
| Classic n-gate.
|
| > > If we encrypt only secret content, then we automatically
| paint a target on those transmissions.
|
| > None of those things are my problem.
|
| > > [HTTPS] guarantees content integrity and the ability to
| detect tampering.
|
| > The legions of browser programmers employed by Mozilla,
| Google, Apple, and Microsoft should do something about that.
| It's not my flaw to fix, because it's a problem with the
| clients.
|
| I re-ordered the quotes a bit, but I'm reasonably confident I
| didn't misrepresent what he was trying to say. The counter-
| arguments after this are good, but the first couple of things
| are, imo, already sufficient to make HTTPS a very very
| important thing.
|
| Though... I find myself wondering whether he's really all that
| wrong, after all.
|
| > Users must keep themselves safe. Software can't ever do that
| for you. Users are on their own to ensure they use a quality
| web client, on a computer they're reasonably sure is well-
| maintained, over an internet connection that is not run by
| people who hate them.
|
| > It's just software. It can't fix your society.
| solarkraft wrote:
| > Users must keep themselves safe. Software can't ever do
| that for you. Users are on their own to ensure they use a
| quality web client, on a computer they're reasonably sure is
| well-maintained, over an internet connection that is not run
| by people who hate them.
|
| And not use insecure websites, I guess. I don't know how that
| person expects the browser to magically protect the user if
| their server transmits in plain text.
| marcellus23 wrote:
| What's the point you're making with your first two quotes?
| Are they supposed to be self-evidently incorrect? If you're
| just serving static content, why should you care whether
| there are governments out there that may be inserting content
| into it?
|
| And while "encrypting only sensitive content calls out that
| content as being sensitive" is certainly true theoretically,
| almost every site has HTTPS, sensitive or not, so in practice
| it's not a concern.
| xhrpost wrote:
| I haven't signed up for a cert in a while, is some form of
| personal/business validation still required? I'm just wondering
| if forcing HTTPS everywhere will make it difficult to anonymously
| own your domain in the future.
| jakub_g wrote:
| https://www.ssl.com/article/dv-ov-and-ev-certificates/
|
| There are several types of certificate. The most basic is DV
| where you only need to upload a file or modify DNS record to
| prove you own a domain.
|
| EV certs used to be visually distinct in browsers but it was
| shown to not be that useful and in fact counterproductive. The
| browsers are going in opposite direction: show nothing special
| for HTTPS, and show red warnings on HTTP.
|
| At this point EV certs are mostly only used by legacy SSL
| sellers to milk rich customers who can't tell the difference.
| 1vuio0pswjnm7 wrote:
| ""It's the browser's job to keep users safe."
|
| True, but incomplete. It is not SOLELY the browser's job.
| Browsers can only keep the users safe if the server provides
| credentials through an HTTPS certificate. As a site owner, it's
| your responsibility to provide these credentials for your
| clients."
|
| HTTPS, or even using the internet in general, is not the only way
| to provide credentials to clients (users). For example, public
| keys can be provided using other protocols or even out of band.
|
| Not every website is engaged in commerce nor otherwise needs to
| "scale" in a way that only computers can enable.
| Evidlo wrote:
| I find certbot a PITA to use and maintain despite the EFF's
| efforts.
|
| And caddy is still not available in the Debian repos.
| MatthiasPortzel wrote:
| Apache now offers mod_md[0], which implements AMCE directly,
| meaning that you don't need certbot. (I don't use Debian
| personally, but it looks like Buster and later support it.) I'm
| sure there are other options for other web servers.
|
| [0]: https://httpd.apache.org/docs/trunk/mod/mod_md.html
| mholt wrote:
| You can thank Debian for that. We've tried for years and
| eventually gave up.
|
| But you can add our source anyway:
| https://caddyserver.com/docs/install#debian-ubuntu-raspbian
| solarkraft wrote:
| What's the deal regarding that?
| francislavoie wrote:
| Packaging on debian requires individually packaging _every
| single dependency_ of Caddy, because that's what they
| require from Go projects. That's way, way too much effort
| for us to spend, for very little gain. So we just have our
| own APT repo, graciously hosted by Cloudsmith, since we can
| automate pushing to there via github actions, on release.
| Freskis wrote:
| The website misses the reason that I have not moved my domains to
| HTTPS: Google.
|
| Google treat the HTTP and HTTPS pages as separate for link
| ranking purposes, so there is a chance that a move will destroy
| 10 years of link ranking. Even with redirects, there is a non-
| zero chance of the business being destroyed.
|
| If Google would treat HTTP and HTTP pages as the "same page" then
| I would move tomorrow.
| spoiler wrote:
| I'm not that knowledgeable on SEO, but thought that this can be
| controlled with the `link rel=canonical` and redirecting.
|
| https://developers.google.com/search/docs/advanced/crawling/...
| mholt wrote:
| Google doesn't penalize redirects from HTTP to HTTPS:
| https://moz.com/blog/301-redirection-rules-for-seo
| mhitza wrote:
| I would suggest an experiment, to move one single (well ranked)
| page to HTTPS, and see the traffic impact over some reporting
| period that makes sense. In terms of Google search, nowadays
| I'm not sure link longevity really matters; otherwise I don't
| think I would get spammy pages consistently as results.
| mhitza wrote:
| I really miss the days when EV certificates where highlighted in
| the address bar. I feel like nowadays it would be easier to get
| scammed, due things like unicode characters in URLs for example.
| mholt wrote:
| Oh, I did my masters thesis about this [1]!
|
| EV certs have long been known to be ineffective at preventing
| fraud. In fact, they can enhance fraudulent activity with a
| false sense of trust. And that's if users even notice it and
| know what it means (most don't).
|
| Chrome has since adopted some ideas from my thesis which
| attempt to warn you if you're at risk based on suspicious
| characteristics of the site you're on, like unusual patterns in
| domain names.
|
| [1]: https://scholarsarchive.byu.edu/etd/7403/
| jakub_g wrote:
| AFAIR someone bought EV certs a few years ago that visually
| looked like apple.com and paypal.com which showed the EV thing
| was useless.
| erwincoumans wrote:
| Didn't realize certificates are really free (according that that
| site), I've been paying GoDaddy $94.99 for a Standard SSL Renewal
| yearly.
| IMSAI8080 wrote:
| ZeroSSL is another one that will give you a free certificate.
| riffic wrote:
| There was a list of all known ACME servers, but it's now
| defunct (boo!):
|
| https://news.ycombinator.com/from?site=https.dev
|
| its last snapshot:
|
| https://web.archive.org/web/20210126194059/https://docs.http.
| ..
|
| source: https://github.com/https-dev/docs/blob/master/list-
| of-acme-s...
| d1lanka wrote:
| Let's Encrypt FTW
| beardog wrote:
| If you change to letsencrypt, maybe route some of that to them?
| bullen wrote:
| No because HTTPS uses more CPU than HTTP.
|
| If all data that is transferred over HTTPS unneccesarily used
| HTTP instead we could close down 10 nuclear power plants.
|
| HTTPS is a privilege that will not stand the test of time nearly
| as well as HTTP, SMTP and DNS!
|
| Edit: I just love this community of downvoters without
| arguments... certificate sellers?
| advisedwang wrote:
| Citation needed.
|
| According to https://www.nature.com/articles/d41586-018-06610-y
| datacenter uses 200TWh/yr which ~= 22GW. Nuclear plants are
| ~1GW, so you're saying TLS is responsible for ~50% of all IT
| power usage?
| bullen wrote:
| Internet uses 84 to 143 gigawatts of electricity every year,
| HTTPS uses the majority of that.
| adgjlsfhk1 wrote:
| That's just because the majority of content is served over
| HTTPS.
| giantrobot wrote:
| Claims without evidence. Most processors released in the
| past decade have some sort of cryptographic acceleration.
| Even before the likes of AES-NI there's been two decades of
| vectorized optimizations for encryption and hash
| algorithms. Sun among others released SSL accelerator
| expansion cards 20 _years_ ago.
|
| The processing overhead for TLS is trivial anymore. You'd
| be hard pressed to find devices (in any market segment)
| sold in the past decade without some sort of acceleration
| or access to vector optimized code paths.
|
| The idea that HTTPS is using tons of extra power over
| exabytes of HDDs spinning up, inefficient microservice
| architectures, or poorly optimized code interpreted code is
| pretty laughable.
|
| But you've made bold claims. I'm sure you've got compelling
| evidence backed by extensive and reproducible testing.
| francislavoie wrote:
| You really think that the simple act of encrypting and
| decrypting the traffic of web requests is the heavy part?
| bullen wrote:
| I know it is, because I made my own HTTP server from
| scratch.
| francislavoie wrote:
| If your site is pure static files, sure, it's added
| overhead. But if you're doing anything dynamic on the
| server, connecting to a database etc, then HTTPS is a
| tiny, tiny percentage of the work being done by the
| hardware. CPUs are very well optimized for these tasks
| these days
| https://en.wikipedia.org/wiki/AES_instruction_set.
| Minor49er wrote:
| Another interesting side effect of not using HTTPS is that other
| sites won't trust yours. In particular, if you try to use Open
| Graph or similar metadata to generate previews that other sites
| can embed when your link is posted, many of them simply won't do
| it because they don't trust the origin.
| mholt wrote:
| Good point! I should update this site and mention that.
| boznz wrote:
| Correct and the real reason I use HTTPS, having "your
| connection is not private.. the site may be attempting to steal
| your information.." come up instead of your web site doesnt
| exactly inspire confidence in your company or its products.
| Graffur wrote:
| While I agree with the premise. What is this about:
|
| "Our site displays ads over HTTP."
|
| Sorry, not sorry.
| enriquto wrote:
| What if you don't trust any certificate providers?
| mhitza wrote:
| You really can't, and there's no easy way to selectively trust
| some. For example, one time I went through the huge list of
| certificate providers in Firefox and manually disabled a bunch
| of countries and only left in a few major providers I heard the
| name of before. My day to day browsing worked just fine, with
| no noticeable impact, but it was not something I can manage on
| a regular and just a one-off experiment.
| remram wrote:
| Trust them to do what? Trust them with what?
| dijit wrote:
| One of the major issues with web PKI is that any root
| certificate authority can sign any domain.
|
| For Google this is fixed by hard coding the SSL hashes into
| chrome, for the rest of us we rely on http headers; which of
| course are much more fungible.
| TingPing wrote:
| The CAA dns type indicates which CAs are allowed to sign for
| a domain.
| dijit wrote:
| If you're in the middle; this is the most trivial thing in
| the world to block; in fact the CAA dns record is so
| limited in what it protects against that I'm genuinely
| confused as to why it exists.
|
| Maybe with DoH it's better. But that's more https to make
| https not suck.
| adgjlsfhk1 wrote:
| If you're using HTTP, you are trusting them not to MITM your
| website already.
| enriquto wrote:
| Yes, so what's the difference?
| bArray wrote:
| > The only reason you should open port 80 on your server is to
| redirect all requests to port 443 and then close the connection
| on port 80. (Someday, maybe we can drop port 80 altogether.)
|
| I think it is fine to support both if you are not handling forms,
| etc. Obviously you prefer people to use HTTPS, but there may be
| cases where HTTP is preferred. One example might be a large
| download where you can verify the hash afterwards, or interacting
| with old hardware/software.
| dijit wrote:
| I think the biggest bug bear with this approach (an approach I
| agree with, fwiw) is that the content of a page can be modified
| to include malicious content, including legitimate looking
| forms.
|
| This wasn't really a widespread problem before "https
| everywhere" became a thing, but it's definitely possible. I
| distinctly remember projects that replaced images with cat
| pictures in-line, or made everything upside down; by exploiting
| the fact that can be modified in transit.
| hamaluik wrote:
| Does your site need to redirect me to the French version
| (https://faut-il-https-sur-mon-site.fr/) just because I'm in
| Canada?
|
| No, no it does not.
| patrickdavey wrote:
| Oddly, I got the Dutch version. I do have Dutch language
| installed on my phone, but it's definitely not the default.
| Odd.
| francislavoie wrote:
| Doesn't redirect for me, also in Canada /shrug
| Naga wrote:
| Me neither. I am even in Quebec, but on an English device.
| mholt wrote:
| It's based on your browser's Accept-Language header, nothing to
| do with location.
|
| (It's only a naive implementation of parsing the Accept-
| Language header. Sorry, was all I could do at the time.)
| remram wrote:
| Yeah you're parser is too broken to be useful. For example
| with this header, listing English and French in that order,
| even explicitly indicating a bad quality value for French:
| Accept-Language: en-US;q=1.0, en;q=1.0, fr-FR;q=0.5, fr;q=0.5
|
| your website redirects to faut-il-https-sur-mon-site.fr. Turn
| this off.
| mholt wrote:
| https://news.ycombinator.com/item?id=30154680
| itsnotlupus wrote:
| Chrome sets it if you tell it you want to use its
| spellchecker with some languages.
|
| I'm not sure what the standard says, but i suspect you'd
| surprise users considerably less if you used the first
| language listed in that header rather than the last (assuming
| equal or missing q values).
| mholt wrote:
| It's been years since I looked at the code/config but I
| literally think it's a "strings.Contains()" call... so not
| even parsing at all.
|
| A proper implementation would make for a good Caddy module.
| RKearney wrote:
| > "HTTPS is difficult to set up and maintain."
|
| > It just works if Caddy is your web server.
|
| I wonder what percentage of people who thinks HTTPS is difficult
| to set up and maintain are able to run their own VPS and properly
| install and configure caddy.
| floatboth wrote:
| If you're not running your own VPS, HTTPS should already be
| handled for you by your hosting provider?
| solarkraft wrote:
| Must be a lot! I'm definitely one of them. Even the allegedly
| simplest to configure server behind Caddy (Traefik) makes https
| unnecessarily hard to configure. Caddy is the long-missing
| counterpart to Let's encrypt.
| ipaddr wrote:
| Letsencrypt is a godsend compared to what we had before. But it
| can be difficult depending on what you run and after a few
| hundred domains things pile up.
|
| You just purchase a domain. You decide to host on apache. You
| first have to setup http get the letsencrypt to perform the
| challenge. Once that's done you can install ssl.
|
| The letsencrypt auto renewer is great until you run a version
| of linux unsupported.
|
| The extra cost per request does add up as well.
|
| The cost to support ssl isn't free but the certificate is and
| pretty seemless all things considered
| MatthiasPortzel wrote:
| I've had issues with certbot in the past as well. Modern
| versions of Apache have mod_md[0], which implements AMCE,
| replacing certbot. Configuration looks like adding 2 lines to
| your Apache configuration file.
|
| [0]: https://httpd.apache.org/docs/trunk/mod/mod_md.html
| francislavoie wrote:
| Caddy replaces both Apache and certbot (or whatever ACME
| client you picked), and runs on any platform Go can compile
| for (because it's pure-Go).
| KennyBlanken wrote:
| For most web hosting providers, enabling HTTPS is a button
| click, if not enabled by default, thanks to ACME and
| LetsEncrypt et al.
___________________________________________________________________
(page generated 2022-01-31 23:02 UTC)