TLS 1.3 and Firefox Android builds from 16.0 onwards

Starting with build version 16.0.x Firefox for Android has TLS1.3 turned on by default. This has implications for anyone trying to login into the luci uhttpd interface on openwrt from an Android tablet or phone using https.
The most obvious symptom is the MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT error when trying to connect. The problem from there on in is that Firefox mobile will not allow you to set the openwrt cert as a permanent exception, it loops round and give you the PKIX_ERROR again. I have raised this as a mozilla bug but do not have much hope that they will accept it Bug. I have attached a number of test certificates to this bug report all of which fail!

There is also a related bug in openssl that causes it to incorrectly mark end user self signed certs as CA certs https://github.com/openssl/openssl/issues/7055.

For more details on TLS1.3 in Firefox see https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Security#TLS_1.3.

This obviously has implications for uhhtpd in openwrt that may need to be addressed.

Comments anyone.

Moved this here from installing and using section.

So what kind of rain dance is required now to make firefox mobile happy? No self signed certs at all anymore?

That is what I have been trying to find out. I have attached most of the things I tried to the mozilla bug. But I have not found anything that is 100% reliable yet. It not made easy by the lack of any reliable cert storage or management on the android port. Just about the only thing you can do is add root ca certs to the firefox cert store. But then you cannot remove them without removing and reinstalling the app. https://support.mozilla.org/en-US/questions/1231106

It will be interesting to see how Mozilla addresses this. There are certainly many enterprise-grade devices that use self-signed certificates. It's not possible to use a service such as Let's Encrypt to obtain certificates without revealing "private" DNS names to the outside world, nor for DNS domains that don't resolve on the public Internet (such as internal use of *.management. or the like). The cost of individual certificates for multiple, internal devices, or for wildcard certificates would certainly make any reasonable IT department complain loudly.

I compared what desktop firefox does in the same situation. From this I realised that you do not have to add the root ca to the cert store for the exception to be added. So to summarise.

  1. The certificate that the default uhttpd installation process generates is in fact invalid. This is caused by the bug in openssl.

  2. You can generate use openssl to generate your own ca certificate and then use to sign a server certificate and supply this signed certificate to uhttpd. You do not need to seperately supply your ca certificate to the browser.

  3. I cannot generate a self signed certificate that can be used as a server certificate by uhttpd and can be added as an exception by the firefox mobile browser.

  4. Using the signed cert exception with the firefox mobile browser produces a very unreliable connection to openwrt. Packet traces of the connection show serious issues with uhttpd that appear to be related to the use of TLS1.3 by the firefox mobile browser. These issues still occur when using the firefox desktop browser but are not as visible to the user.

Conclusion. A right bag of worms, or as we say round here. A dog's breakfast.

p.s. I am subscribed to this topic but not getting any notifications.

Note that there are TWO different uhttpd certificate generation commands. One is via px5g for the main default mbedtls, while the other was added two years ago by me for the openssl variant. It follows the mbedtls command as far as possible:
https://github.com/openwrt/openwrt/commit/3c4858eeb2bbb3107f87bb3be07d5c172c8e0ef9#diff-9248d67982f12211b222bf008980eac8

Both variants are simplifications, as no CA is created first but the self-signed certificate is created with an one-line command.

I am not quite sure of the relation between your 2 and 3. Is 3 only about mobile?

Ps.
Note that as a separate issue, Firefox has performance trouble with multiple unrelated certificates from the same-named CAs, so to avoid that, the O= field is made unique in our certs. Link to Firefox bugs can be found in my commit message: https://github.com/openwrt/openwrt/commit/9097dc5ad844c336020be11085e1c8c80390ac9c#diff-9248d67982f12211b222bf008980eac8

hnyman

All the items refer to firefox for android a.k.a firefox mobile.

I am running Lede SNAPSHOT, r6302-0f54d96d24 on a wrt1200acsv2 It does not have mbedtls installed so defaults to openssl. The version of uhttpd is 2017-11-04-a235636a-1.

I am loath to update the firmware as it never seems to go smoothly. I only embarked on this journey because I was going into hospital and may have needed to manage the router remotely. Since then they have cancelled on me.

I am getting to the end of my rope with the compkexity of this and do want to search through 250,000 source files to find the bit code that implements the check on self signed certificates that firefox mobile implements to see what it is actually checking!!!

I can live with using the dekstop version for the time bring. Although it was certainly an eye opener to look at the packet traces to see all the rubbish that was going on.

Ok.

I had a conversation with the guys at openssl. The view there is that "openssl req -x509" is for generating CA root certificates and we should be using "openssl x509 -req" for generating self signed end entity (EE) certificates.

However, I generated a self signed cert this way and installed it in uhttpd. Unfortunately Firefox mobile still has a problem with it. These are the commands I used to generate the certificate.

openssl req -sha256 -newkey rsa:2048 -keyout openwrt.key -out openwrtreq.pem -subj /C=ZZ/ST=Somewhere/L=Unknown/O=OpenWrt/CN=OpenWrt -nodes

openssl x509 -req -in openwrtreq.pem -signkey openwrt.key -out openwrt.crt

I had already done a series of tests comparing the network traffic generated when apache2 and uhttpd are both set up with identical certificates. This showed that firefox only had the problem when it was talking to uhttpd. This is also the case when using the self signed cert described above.

I would appreciate help on analysing this further.

Being able to turn on debug logging in uhttpd would help!

The saga of Firefox Mobile, uhttpd, and openssl

Simple Conclusion

uci set uhttpd.main.redirect_ssl=0

The story so far

If you install openssl on openwrt, then the install procedure will silently switch uhttpd to using ssl/tls. This is true for manual installs or for automatic dependency installs.

You will probably not notice anything different until you come across a browser that cannot handle the default self signed certificate that is generated by the /etc/init.d/uhttpd start script.

The prime example of this is version 16 and above of the Firefox Mobile Browser that is used on Android (and IOS).

Testing this certificate by converting it to pem format and using openssl verify gives the following.
roger@dragon:~/ssltest/test-certs$ openssl verify -verbose default-openwrt.crt C = ZZ, ST = Somewhere, L = Unknown, O = OpenWrt, CN = OpenWrt error 18 at 0 depth lookup: self signed certificate error default-openwrt.crt: verification fails
Most desktop browsers including firefox show an error message and allow
you to add a temporary or permanent exception for this certificate. However Firefox Mobile shows the error message but when asked to add the exception silently fails and goes back to showing the error message.

The default /etc/ssl/openssl.cnf installed by opkg causes this certificate to be generated the following x509v3 extensions.
X509v3 Subject Key Identifier: 32:4A:35:79:43:5E:93:38:88:94:E0:DE:A2:8E:E3:97:16:C4:EE:D0 X509v3 Authority Key Identifier: keyid:32:4A:35:79:43:5E:93:38:88:94:E0:DE:A2:8E:E3:97:16:C4:EE:D0 X509v3 Basic Constraints: CA:TRUE

These extensions say that the key is a CA root certificate and is only valid
for use as a trust anchor at the top of a certificate chain. However, THIS
IS A RED HERRING(a distraction from the real problem).

The more fundamental problem is that uhttpd returns an encrypted alert the content of which causes Firefox Mobile to terminate the tcp connection. However it does continue to try a few different tls ssl all of which terminate with an unencrypted alert showing a self signed validation error. This is all invisible to the end user, who only sees the browser going back to show the self signed error message and ignoring the attempt to add a security exception.

To muddy the picture even further. If I add the exact same certificate and key to a test site hosted by apache then Firefox Mobile succeeds in adding the security exception and proceeds to connect to the site.

If anyone wants to investigate this further, they are welcome to, but I have had enough. Decoding encrypted alerts is not easy. I will help out if I can.

I have implemented my simple solution above. I do not need to secure my router admin with SSL.