pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[jrmwvu04]

https://support.apple.com/en-us/HT210176

All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:

• TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
• TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
• TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

• TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
• TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

 

[jrmwvu04]

The gist of it is that the certificates that pixelserv generates (the _.whatever ones) use 1024 bit RSA - this is specified in pixelserv code irrespective of the ca.crt you supply to it. I saw mention of that on GitHub and have confirmed it independently by examining my generated certificates. Both of those new operating systems now reject these certificates as invalid and tls handshake fails.

 

[gattaca]

The gist of it is that the certificates...

^^^
WOW! Hmm.. so if I get this:

1. without the proper updated certs from/to pixelserv, this change from Apple on the "tightening of the certs" breaks all iOS and macOS current support b/c pixelserv's generated certs do not comply. Though... the "DNS Server Name" might be a challenge as that would be the name of the router? (192.168.100.x or whatever it's name really is in the Merlin?)
2. even if we figured out the cryptic commands to generate our own certs using openssl, they cannot be used by pixelserv?

I had to deal with something similar with VMware and certs a few years ago where the CSO called out min key lengths and the default keys did not comply. Talk about a PITA.

FWIW, 2048 is pretty much the minimum acceptable standard today from a CSO perspective.

The first 3 can probably be handled using openssl, the last two, there may be some esoteric openssl keys to do that, I do not recall. It's been a few years since I ferreted around in openssl to generate certs. But if there's no way to get pixelserv to use them or get the names right, this is about to break a lot of stuff. Is this something amtm might help with? I'm suggesting b/c I recall openssl command lines are not what I'd call friendly.

 

[Mutzli]

The gist of it is that the certificates that pixelserv generates (the _.whatever ones) use 1024 bit RSA - this is specified in pixelserv code irrespective of the ca.crt you supply to it. I saw mention of that on GitHub and have confirmed it independently by examining my generated certificates. Both of those new operating systems now reject these certificates as invalid and tls handshake fails.

Did you PM kvic about this upcoming issue? I know he usually is only active here when he works on an updated version of pixelserv -tls. It might be hard to get hold of him.

 

[elorimer]

• TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

• TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID

Aside from the key length, these sound like they are aimed at the concept of pixelserv.

• TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

And pixelserv is 10 years.

 

[gattaca]

And pixelserv is 10 years.
^^^
That's why I mentioned that getting these certs right in openssl could be a PAIN with all the right keys.

Also, most CSO require the maximum validity period of certs is 24-36 months. They do not like / permit certs expiring out more than that time. Call it "tightening down the certs"...

 

[Marin]

Would this be helpful?

https://hohnstaedt.de/xca/


Sent from my iPhone using Tapatalk

 

[thelonelycoder]

https://support.apple.com/en-us/HT210176

All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:

• TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
• TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
• TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

• TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
• TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

This is a medium emergency IMHO for the continued operation of pixelserv-tls on our routers.
Most of it has to be addressed by @kvic while I can (probably) fix it with an updated pixelserv-tls certificate generation in Diversion.
At the moment the generation of the ca.crt and ca.key is done with the following command in Diversion:

openssl genrsa -out ca.key 1024
openssl req -key ca.key -new -x509 -days 3650 -sha256 -extensions v3_ca -out ca.crt -subj "/CN=Pixelserv CA"

Generating a 2048 bit key is trivial, also the expiry date for it. But the other requirements need to be addressed as well.
Code examples are very welcome.

 

[gattaca]

Would this be helpful?
https://hohnstaedt.de/xca/
Sent from my iPhone using Tapatalk

Yes, the challenge is deciphering and knowing exactly WHICH fields are required to satisfy the cert/key generation request. Yes, key length is the easier part. That vid shows just a few of the variations. If someone can translate what parms are required in openssl, that's the hardest part. We spent days trying to get things right b/c the code was looking for this common-name or that.

Example mapping requirements like this "an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID" to openssl commands correctly - might as well be in written in gibberish.

Maybe we can pick the openssl command apart and find the right parms or maybe someone has an example which meets Apple's requirements??? I'm going to reinstall openssl on my Windows box... if you need openssl for Windows to play around, it's here -> https://slproweb.com/products/Win32OpenSSL.html
or another viable way -> https://computingforgeeks.com/install-openssl-on-windows-server/

OK here's the notbefore/notafter but it has to be in that crazy format..? It may be easier to supply a openssl.cfg file with the right parms to play around?

If you use the openssl ca tool, use -startdate date and -enddate date command line options or using default_startdate and default_enddate in [ca] section of the config file.

The DNS name has to be in the subjectAltName field or listing.. So what DNS name would be used?

[ my_extensions ]
basicConstraints=CA:FALSE
subjectAltName=@my_subject_alt_names
subjectKeyIdentifier = hash

[ my_subject_alt_names ]
DNS.1 = *.oats.org
DNS.2 = *.oats.net
DNS.3 = *.oats.in
DNS.4 = oats.org
DNS.5 = oats.net
DNS.6 = oats.in

DNS name should be specified with ":" and separated with comma by leaving no space between 2 entries so something like this on a command line? I read the IP: is also required in some instances from the other thread... So you would need to define a local domain in the ASUS router and then use that to generate the certificates? IDK, I'm asking..

DNS:mystuff01.mydomain.com,DNS:mystuff02.mydomain.com,DNS:mystuff03.mystuff.com,IP:192.168.100.2

Here's an example showing what type of entries go int the SAN / DNS
https://knowledge.digicert.com/solution/SO18140.html#Validity

 

[Butterfly Bones]

Would this be helpful?

https://hohnstaedt.de/xca/


Sent from my iPhone using Tapatalk

Here is the thread by RMerlin about that tool.
https://www.snbforums.com/threads/tool-to-manage-your-own-certificate-authority.45062/

 

[thelonelycoder]

Offline until Sept. 2019, apartment renovation. Travelling...

Be safe on the road with your supposedly bad eyesight

 

[jrmwvu04]

Did you PM kvic about this upcoming issue? I know he usually is only active here when he works on an updated version of pixelserv -tls. It might be hard to get hold of him.

To be honest I've been concerned about him. For those of you not following the news, Hong Kong is not an ideal place to be lately. To quote another user, the silence is now worrisome.

This is a medium emergency IMHO for the continued operation of pixelserv-tls on our routers.
Most of it has to be addressed by @kvic while I can (probably) fix it with an updated pixelserv-tls certificate generation in Diversion.
At the moment the generation of the ca.crt and ca.key is done with the following command in Diversion:

openssl genrsa -out ca.key 1024
openssl req -key ca.key -new -x509 -days 3650 -sha256 -extensions v3_ca -out ca.crt -subj "/CN=Pixelserv CA"

Generating a 2048 bit key is trivial, also the expiry date for it. But the other requirements need to be addressed as well.
Code examples are very welcome.

Yeah, the heart of this issue is that the changes to how the keys are generated need to be made inside of pixelserv itself. As you mention I figured out easily to change the RSA and the issue length. With some googling I think I have seen a workable solution for adding ExtendedKeyUsage. But doing this in the certificate you make yourself isn't sufficient because pixelserv generates all the individual certs with its own settings regardless of what your supplied certificate contains. I am going to have to set up an environment again to be able to build pixelserv from source so I can tinker with it. I've done it before with the macOS/homebrew thing but frankly I'm an idiot stumbling around in the dark when it comes to this sort of coding - @kvic fixed all of the issues, I merely discovered that there was a problem.

 

[jrmwvu04]

Here's what the current result is from the latest pixelserv build widely available. 10 years, 1024 bit, etc. despite the supplied certificate being changed.

 

[thelonelycoder]

Yeah, the heart of this issue is that the changes to how the keys are generated need to be made inside of pixelserv itself.

I'm sure that iOS 13 will not allow to add the current pixelserv-tls certificate in the profile settings.
That's where Diversion would have to offer an option to re-create the certificate with the new settings.

 

[thelonelycoder]

I am reluctant to test iOS 13 again. I had my iPadPro on iPadOS 13 beta for a while but some apps don't work on that new OS so I downgraded back to 12.4.

 

[gattaca]

Here's what the current result is from the latest pixelserv build widely available. 10 years, 1024 bit, etc. despite the supplied certificate being changed.

Interesting, close? So above we see
a) the not/before, not/after, just need to back off the 10 years? -days 825
b) increase the bit key length to 2048
c) interesting there's a DNS name in the SAN already. I read somewhere it needed to also specify the IP. I'm not sure about using wildcards? Is this where the router's name and IP would go or will this still work as-is? This is where I really don't know if you would need to user your router's name+your.local.domain.name + router's IP + pixelserv's IP?
d) Make the common name = SAN DNS name I read was advised for now.

This is what the current cert shows with some info masked from the AC86U. It takes the entries from combos of device name + IP of AC86

192.168.100.7 router.asus.com x123-10007-AC86 x123-10007-AC86.mydomain.mycom ??

 

[jrmwvu04]

I'm sure that iOS 13 will not allow to add the current pixelserv-tls certificate in the profile settings.
That's where Diversion would have to offer an option to re-create the certificate with the new settings.

Currently I'm working with macOS because it's just easier to sit behind one keyboard to do testing. iOS behaves similarly, but doesn't give the user as many specifics. All of this pertains to Safari, by the way. I am not sure how or if other browsers are affected yet.

It's worth noting, I think, that it's not the end of the world that the handshake fails. pixelserv and by extension Diversion will still be quite useful and functional even while a solution is being worked out.

 

[thelonelycoder]

Currently I'm working with macOS because it's just easier to sit behind one keyboard to do testing. iOS behaves similarly, but doesn't give the user as many specifics. All of this pertains to Safari, by the way. I am not sure how or if other browsers are affected yet.

It's worth noting, I think, that it's not the end of the world that the handshake fails. pixelserv and by extension Diversion will still be quite useful and functional even while a solution is being worked out.

I'll fire up my mac mini, update it and do some tests.

 

[Asad Ali]

I'm sure that iOS 13 will not allow to add the current pixelserv-tls certificate in the profile settings.

It does allow to add but Safari gives warning when you try to access pixelserv IP for first time, you need to force allow it. But it's kind of useless now because you'll have to force allow it for every domain in the block list separately.

 

[Treadler]

It does allow to add but Safari gives warning when you try to access pixelserv IP for first time, you need to force allow it. But it's kind of useless now because you'll have to force allow it for every domain in the block list separately.

I am in an Apple iOS scenario.
So, if iOS13 breaks pixelserv, what is the result if I have to remove/disable pixelserv?
Does that in turn reduce, or break the effectiveness of Diversion?