Preventing Letsencrypt 3rd party clients going the Android way?

Client dev
#12

so pretty much like veryfying ownership of domain for Google Webmaster tools put a file on the domain and finish.

I didnt think that this was an LE specific term, obvious that I found nothing that makes sense on Google

#13

Yup basically the same :slight_smile:

#14

With Android defragmentation with every phone manufacturer having their
own Android builds, the responsiveness to updates for patches to
stagefright etc have been slower.

There are two issues to consider.

First, “early” version of Android suffered the problem. Early versions are versions prior to Ice Cream Sandwich (ICS). These devices also had the certificate store burned into ROM and part of the image, so there was no way to update it. The OEM abandoned the devices after the sale, and there’s nothing you can do about it to fix it.

Second, “later” version of Android address the problem. Ice Cream Sandwich (ICS) allows the certificate store to be updated in the field without a new image. For details (and some very good reading), see Nikolay Elenkov’s blog Android Explorations and his article ICS Credential Storage Implementation.

A final issue to consider is Apple and Windows Phone suffers this too. They abandon OS’es as quickly as some of the phone manufacturers. Its mentioned as a footnote because this discussion concerned Android.

An interesting facet of the problem on Windows Phone: OEMs are contractually obligated to apply Windows Phone updates. For a discussion, see Alan Meeus’ Windows Phone: Security Deep Dive . However, it does not address (1) what Microsoft puts in the store (or omits from the store); and (2) Microsoft abandoning the operating system.

(And sorry about not providing links. This stupid bulletin board software made me take them out).

#15

well win phone maybe but apple? e.g. the iphone 4s came iirc up to ios 9 which is quite some way and a lot longer than most of the androids.

#16

@schoen @kelunik @bmw @jsha @jcjones

I was checking the stats at https://letsencrypt.org/stats/ and see last 24hrs still alot of simpleHttp verifications compared to http-01. As i understand it simpleHttp is going away and new LE client uses http-01. So this infers that alot of folks are still running outdated LE clients ?

Any planned mechanisms in place to ensure and inform LE users to update their LE clients to keep updated ?

does the LE client have it’s own version number it can report ? maybe add to https://letsencrypt.org/stats/ LE client version stats as a reminder for folks to update too

#17

Would be nice to have some kind of user agent logging to know which clients are used. Actually I like the simpleHttp spec currently better, but there’s always an issue for that on GitHub…

1 Like
#18

actually had a suggestion for a --client-type flag Standalone, Manual, Webroot stats?

#19

We don’t need a flag, the client already knows which plugin is used and could report that in the user-agent header.

1 Like
#20

but a flag for tracking 3rd party client implementations which wish to pass on their identification to LE servers ?

#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.

[Webroot] Only performs http-01 challenge which doesn't follow HTTP redirects to HTTPS site
#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 https://github.com/letsencrypt/letsencrypt/issues/1343 and https://github.com/ietf-wg-acme/acme/pull/7

oh and https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE_LNhnt0d8U

[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).

https://serverfault.com/questions/458106/apache2-default-vhost-in-alphabetical-order-or-override-with-default-vhost
https://serverfault.com/a/180956

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