Preventing Letsencrypt 3rd party clients going the Android way?

Client dev
21

3rd party implementations don’t use the client at all.

22

by the way where’s the difference between simpleHTTP and http01, both were iirc some kind of webroot werent they?

23

yeah but was thinking about tracking 3rd party implemented / obtained cert stats

so on stats page you can see how many ssl certificates are obtained from various 3rd party implementations as well so gives you an idea of popularity of 3rd party vs official LE client implementations

24

Yes, that’s what a user-agent in HTTP is actually designed for.

1 Like
25

http-01 doesn’t allow the tls challenge property and requires http:// instead of either http:// or https:// (default is tls: true in simpleHttp).

1 Like
26

so HTTP-01 will have problems on the HTTPS-only domains I use? (or does it still follow HTTP to HTTPS redirects) too bad. the question that I wanna know is, what is used with manual mode?

27

[quote=“kelunik, post:24, topic:2071, full:true”]
Yes, that’s what a user-agent in HTTP is actually designed for.
[/quote] @kelunik ah i see :slight_smile:

28

It still follows any redirects, at least currently. However, there was this commit: https://github.com/ietf-wg-acme/acme/commit/3f8604cf02ab740c16c495e563f3619d59496409

1 Like
29

so now they try to kill HTTPS and self-signed certs as a intermediate step before getting LE? too bad.
if HTTP is allowed then Self signed and HTTPS should also be allowed.

30

IIRC the simpleHttps https verification had a security issue which forced the change to http - not entirely sure it's discussed in some of the LE github issues

edit: found them at Support HTTP01 over SSL · Issue #1343 · certbot/certbot · GitHub and Address default virtual host risks by bifurcation · Pull Request #7 · ietf-wg-acme/acme · GitHub

oh and [Acme] ACME vulnerabilities in SimpleHTTP and DVSNI due to common webservers' default virtual host semantics

[Acme] ACME vulnerabilities in SimpleHTTP and DVSNI due to common webservers' default virtual host semantics

Apache (and I gather nginx too) have the subtle and non-intuitive
behaviour that if a default TLS/HTTPS virtual host is not configured
explicitly, one will be selected based on the ordering of vhosts in the
webserver configuration (in practice, this often amounts to alphabetical
ordering of files in a configuration directory).

apache 2.2 - Apache2 default vhost in alphabetical order or override with _default_ vhost? - Server Fault
virtualhost - nginx is defaulting all requests to, what should be, a vhost - Server Fault

This creates a vulnerability for SimpleHTTP and DVSNI in any
multiple-tenant virtual hosting environment that failed to explicitly
select a default vhost [1]. The vulnerability allows one tenant
(typically one with the alphabetically lowest domain name -- a situation
that may be easy for an attacker to arrange) to obtain certificates for
other tenants. The exact conditions for the vulerability vary:

  • SimpleHTTP is vulnerable if no default vhost is set explicitly, the
    server accepts the "tls": true parameter as currently specified, and
    the domains served over TLS/HTTPS are a strict subset of those served over
    HTTP.
  • DVSNI is vulnerable if no default vhost is set explicitly, and the
    hosting environment provides a way for tenants to upload arbitrary
    certificates to be served on their vhost.
1 Like
31

list of 3rd party clients is growing at List of Client Implementations so hopefully concerns about fragmentation and keeping up with official LE client changes is low :slight_smile:

example Conceptual Issues with operational handling of letsencrypt