pfg

Convincing users to grant access to a USB device when they're attempting to log in to a service using said USB device sounds like something that would work more often than not. We wouldn't need phishing-resistant authentication methods if humans were good enough at making those kinds of decisions.

There is a permission prompt, but it's fairly easy to convince users to accept it during a login attempt when they're expecting their USB U2F device to be used.

They're not claiming the certificates were compromised because of their own practices, in fact they repeatedly emphasise that there was no issue on their end.

I'm not questioning that the certificates became compromised the moment they sent them via email, or really the moment they generated and stored them given the level of security competence they've shown thus far.

Symantec is already getting distrusted and the Web PKI community has decided on a plan that minimizes user impact while doing that. It's very doubtful that a company as incompetent as Trustico has the expertise to come up with a more well-informed decision or a better approach. Certainly attempting to get 50,000 certificates revoked immediately without doing any work to reissue those certificates prior to that is a terrible approach.

Considering the fact that they recently switched to a new CA partner, a more likely explanation is that this was a misguided attempt to somehow keep their existing business rather than let DigiCert pick them up somehow. Obviously it failed in a spectacular fashion.

To clarify, other certificate types do not judge content either. The difference is that they verify your organisational details (to a varying degree, depending on the validation level) and include them in the certificate. The CA is not going to check whether the business is fraudulent or anything like that.

He's arguing that the various issues that lead to Symantec being gradually distrusted mean that they believed all their existing non-expired, non-revoked certificate were compromised (in the sense that they should not be trusted) and should be revoked.

Maybe it's just me, but a company who stores their customer's private keys, sends them around in a ZIP file via email and has a trivial code injection vulnerability on their site, with a process running as root, is probably not the one I want to make that call.

> The secondary part is that they requested mass revocation of active certificates, including from brands such as RapidSSL which were not being browser distrusted AFAIK (even though some others were.. if I need to be corrected on this please let me know).

To my knowledge all CAs under Symantec's control, including RapidSSL, are affected[1], with only a handful of exceptions for cross-signed intermediates where Symantec was not under control of issuance. IIRC they belong to Apple and Google (and maybe a few others).

[1]: https://security.googleblog.com/2017/09/chromes-plan-to-dist...

Trustico now posted a statement on their site[1]. My favourite part is this:

> Trustico® followed the requests of DigiCert by initially recovering Private Keys from cold storage and subsequently e-mailing the associated order number and Private Keys to DigiCert in a ZIP file. The file did not contain any other type of data.

[1]: https://www.trustico.com/news/2018/symantec-revocation/certi...

This is not wrong, but in the context of them generating and storing private keys for their users it means there's nothing in the Baseline Requirements preventing them from doing so if the subscriber (user) agrees to it.

However, even if we assume Trustico was an authorized party, the keys became compromised the moment they were disclosed to DigiCert unless the terms their users agreed to included DigiCert as an authorized party. Even if they were you could make an argument that those keys were compromised due to the fact that they were literally sent via email, unless they were properly encrypted and what not.

Not all parts of the source code are available under the same license. The individual source code files include the applicable license. Doing this is fine for compatible licenses and not unusual for projects, though it can make certain things more complicated. Here's an example of what GNU says about GPL compatibility[1] - roughly meaning the whole work is published as GPL.

[1]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

Researchers have found many, many flaws in Estonia's e-voting system[1].

[1]: https://estoniaevoting.org/

One way that sites can use this service is to check whether a password has been leaked when users sign up. By handing over the SHA-1 hash of the password you're effectively trusting this service (and anyone who might have compromised it) with all your user's clear text passwords. Connecting the right password with the right user can be trivial in some circumstances, say because a site has a publicly visible sign-up date on profiles, or even if it just hands out sequential IDs to users.

kiallmacinnes already mentioned that rate limits have no effect on renewals, but more importantly: There's a fairly simple process to bump rate-limits if your use-case requires it[1].

[1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...

U2F is the only generally available two-factor method that is phishing-resistant. Phishing accounts for a large percentage of targeted attacks, something that is highly relevant in a threat model for journalists.

The most notable exception to this would be Chrome OS (which also served as a starting point for CoreOS and, IIRC, Google's container OS).

This hasn't stopped Google from using a Debian variant internally as a desktop OS, so they all kind of have their place depending on what you intend to build.

Generally speaking, Chrome uses whatever is in the OS trust store, with certain exceptions for CAs that have been naughty (e.g. StartCom, WoSign, Symantec) or subCAs that were revoked via CRLSets. Private CAs present in the OS trust store will generally just work, the only exceptions being things like Superfish.

It's fairly trivial to request a rate limit adjustment from Let's Encrypt[1].

[1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...

Users often have very little choice when it comes to their ISP. Regional ISP monopolies are very much a thing in many countries.

Safe Browsing is implemented in a fairly privacy-preserving way. The block list is downloaded periodically and sites are checked against this list locally. The only time most browsers implementing Safe Browsing will share potentially privacy-sensitive data is when you download executable files and when you actually encounter a site included in the block list (in order to double-check whether the site has since been removed).

Documentation for the Safe Browsing implementation in Firefox can be found here[1].

[1]: https://support.mozilla.org/en-US/kb/how-does-phishing-and-m...

The courts recently ruled on a similar case[1] and came to the conclusion that it was not a CFAA violation. That said, there's a difference between a public website such as LinkedIn and a host that just happens to be reachable over the internet, so I'm not sure it would be fully applicable.

[1]: https://arstechnica.com/tech-policy/2017/08/court-rejects-li...

It's generally a good idea to avoid JWT. There are a lot of foot-guns in JWT, and many implementations have gotten it wrong in the past. This[1] is a good summary on the topic.

[1]: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...

> What would be insecure about a https-01 challenge, that esentially works identical to the http-01 challenge but allows any certificate?

There's a specific reason http-01 is HTTP-only, and it's actually quite similar to the tls-sni-01 situation. In many of the major web servers, including apache and nginx, the web server will use the first HTTPS vhost in its configuration for any unmatched domains, unless you explicitly specify a default vhost. In practice that means an attacker on the same hosting environment used by the victim could get themselves in a position where they control this default vhost and obtain a certificate for their domain. The vhost order is often based on the alphabetic order of the domain, so that's fairly easy to pull off. http-01's predecessor did allow HTTPS, but this attack came up during the IETF ACME standardization process and, IIRC, was fixed before Let's Encrypt entered public beta[1].

http-01 does permit the CA server to follow redirects to HTTPS, including to ones with self-signed, expired or otherwise invalid certificates, so common setups with HSTS and redirects to HTTPS are fine, you'll only be in trouble if you can't use HTTP on port 80 at all.

[1]: https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE...

An option that's often overlooked is to use a CNAME record for the _acme-challenge label pointing to a domain under your control. acme-dns[1] explains this approach in detail.

The usability of the HTTP and TLS challenges is still better in most cases, but that would give you an alternative in scenarios where neither is an option for some reason.

[1]: https://github.com/joohoi/acme-dns

Thanks. I signed up for the first shared web hosting provider I could find that uses DirectAdmin and was able to reproduce this. I'll bring this up in the relevant thread on mozilla.dev.security.policy, this is definitely concerning.

> Is this a problem for Let's Encrypt? Doesn't Let's Encrypt's verification require creating files with random names in http://example.com/.well-known/acme-challenge where example.com is the certificate's common name?

That applies to the http-01 challenge. The tls-sni-01 challenge works solely based on the returned certificate. If the SAN value in the certificate matches the SNI value sent by the validation server, the challenge succeeds.

Would you mind sharing which control panel you tested this with?

It eliminates one possible foot gun.

A web host or CDN might allow arbitrary domains to be added, and arbitrary certificates to be uploaded for said domains, all without any validation. That would ... not be my favourite implementation, but if you didn't know about how the Web PKI and ACME works, that's an implementation you might come up with and not expect a whole lot of issues.

However, it's unlikely that the web host would allow you to do this for a domain already associated with an account, or a subdomain of such a domain. Unlike the first case, this would effectively allow an attacker to fully control any subdomain, so even without any Web PKI involvement, that would be a vulnerability in and of itself.

It remains to be seen what the two affected providers were actually doing, and I don't really have enough data to make a call on whether it's actually worth changing this aspect of tls-sni-02, but it's something to consider.

> Is it possible to make Caddy deterministically use the capabilities of the ACME protocol to try the intersection of challenges you want to use, and the ACME server supports? No. It's not.

Very, very few ACME clients have a renewal mechanism that supports automatic fallback to a different challenge type. I know a couple and the only one I can think of is certbot, and even there that's only true if you use the standalone or manual plugin (the others don't support "--preferred-challenges").

However, if your question is "Can I make Caddy use the exact challenge type I want it to", then the answer is yes, as you can guess from the "-disable-tls-sni-challenge" flag. This is what most clients will let you do. No one is saying that those clients can't renew with manual intervention.

> The rest is fucking moot. My point in every one of these threads is that Caddy is presented as "it just works" until it fucking doesn't and you have the weirdest shit happening.

You're changing goal posts.

> With regular tools, it's expected that you have a clue what the fuck you're doing and configure it to meet your requirements.

Part of knowing what you're doing as a developer is knowing that you either have sane defaults or stuff is going to break for a lot of people.

> Inexperienced people may use certbot and end up needing to do something. Sure. But I don't expect inexperienced people to be managing production environment servers. Do you?

Are you implying anyone using the default instructions for certbot is inexperienced?

> You claim Caddy's defaults are better - thats an opinion, but the problem is it's not a "default" it's forced fucking behaviour. You simply can't tell it to operate sanely like you can with certbot + haproxy.

If you think you can do better with your own approach, by all means do that. Most people are not PKI or ACME experts and won't have the necessary knowledge to make all the right calls, so they're better off with a "managed" solution like Caddy.

To be clear: This is an edge case and I'm in no way saying the certbot team is incompetent because they did not foresee this scenario and handle it as part of the default setup. It's just silly to go on about how terrible Caddy is when they happen to have a mitigation in place.

> This whole thread is responding to the author of Caddy saying specifically that people need to intervene or Caddy won't necessarily renew properly.

No, that's not what Matt said:

> Your sites will likely not go offline even if you do not use this flag because Caddy tries up to 2 times per day, 30 days out, to renew an expiring certificate, as long as you keep it running.

> the TLS-SNI authorisation will either still be valid, and it will renew as expected, or it will need to re-authorise via challenge, and it will fall back to the http challenge as I just demonstrated

This is not an accurate description of how you'd be affected with typical certbot deployments. Two examples:

Debian Stretch with apache2. Certbot's website recommends the following command:

    sudo certbot --apache

Currently, this fails with the following error message:

    Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

Same OS, nginx. Certbot recommends this command:

    sudo certbot --nginx

This causes the same error.

Renewal would fail with the same error message; You can find examples on Let's Encrypt's Community Forum if you don't believe me[1].

Is it possible to set up renewal in a way that would cause certbot to fall back to a working challenge? Sure. But it's far from common or even the default.

> If you follow the standard setup for Caddy you have a 50/50 chance of getting a cert today. Either you accept that people can deviate from the most basic "this is how you can run it as an example" or we stick to the defaults both ways. Claiming "oh but the standard setup.." when this issue requires caddy users to change their freaking init/sevice files is disingenuous.

Again, you're misinterpreting what Caddy does. Renewal will only fail if you're unlucky 60 times in a row, as opposed to 100% of the time for most clients in common scenarios.

[1]: https://community.letsencrypt.org/t/client-with-the-currentl...

It's definitely an option, but the question is whether someone who has set up certbot at some point in the past will benefit from it without manual intervention (as is the case for Caddy). If you're following the standard setup, using the instructions on certbot's website, you'll select exactly one plugin (with each plugin mapping to one challenge type, unless you do something fancy), and if that challenge type goes away, manual intervention is required.

If tls-sni-02 is affected too (as Josh indicated it probably is below), I'd suspect something like a major CDN or hosting provider allowing deployment of arbitrary, attacker-controlled certificates on arbitrary domains under "acme.invalid". That would be the only thing I can think of that would bypass the "anti-parrot" mitigation introduced in -02.

Otherwise, it's probably what you're describing.