iOS 13 and HTTPS Inspection

[Jollity]

I think I have found a source of headaches for those applying HTTPS inspection to iPhones. I have not done as much testing on this as I would like, but thought I should get it out there because it seems to check out and I have not found anyone else talking about it.

 

One of my colleagues updated his iPhone to iOS 13 yesterday when this new update was released and now receives certificate invalid errors on HTTPS pages tested (in Safari) when using our BYOD wi-fi network, which is HTTPS inspected by Smoothwall. We checked the "Enable full trust for root certificates" settings we have had to start setting since iOS 10.3.

 

It appears that iOS 13 introduced new requirements for HTTPS certificates to be treated as valid: Requirements for trusted certificates in iOS 13 and macOS 10.15.

In particular the one that seems to be catching out Smoothwall is: "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 have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate)." This would not affect our Smoothwall root certificate for HTTPS inspection (as that claims to be issued ages ago), but all the certificates issued for individual sites are issued recently and have a validity periods of 831 days.

 

 

I am not sure if this will affect iPad OS, arriving next week, but if it does it would definitely be a reason we would not be pushing that out to pupil iPads yet.

[k-strider]

And so it begins..... we are worried about this too with our firewall.... we noticed it in the beta....

http://www.edugeek.net/forums/security/207194-new-tls-security-requirements-ios-13-macos-catalina-10-15-a.html

We got internal certificates to work like this.... we have 3 year groups with ipads

[Jollity]

I see I did not search enough for previous discussions. Sounds like on Smoothwall it is fixed but we have to recreate our CA, which will be a rather a pain to distribute to all the BYOD users.

http://www.edugeek.net/forums/smoothwall-direct-support/208719-create-https-inspection-certificate-validity-825-days.html

 

Also on this issue: http://www.edugeek.net/forums/netbooks-pda-phones/208249-ipados-13-firewall-issues.html

[RLR]

It seems to be a smoothwall issue? We use Fortinet and don't have this issue.

[DalekSec]

We didn't have an issue with our MITM Cert in iOS 13, as our provider, Netsweeper changed the Cert thankfully. But now we have an issue with iOS 13.1! Their fix? Don't update..... have a good few students update to 13.1 and we're unable to put them on the WeeFee Edited September 21, 2019 by DalekSec

[Opendium_Steve]

Uh oh... this isn't one I've come across yet.

 

With such a short validity period, how are people handling the regular certificate replacement on non-MDM devices? It seems hard enough getting people to install the certs in the first place.

 

 

Also another one I heard today - apparently Chrome on Android 9 is now ignoring MITM certs? (That was literally reported to us a couple of hours ago so not had chance to verify it - quite worrying if true though!)

[Primus]

It seems to be a smoothwall issue? We use Fortinet and don't have this issue.

 

It's not a Smoothwall issue specifically, the OP gives details on how Apple are now deciding on a certificate's validity.

[Primus]

Uh oh... this isn't one I've come across yet.

 

With such a short validity period, how are people handling the regular certificate replacement on non-MDM devices? It seems hard enough getting people to install the certs in the first place.

 

 

Also another one I heard today - apparently Chrome on Android 9 is now ignoring MITM certs? (That was literally reported to us a couple of hours ago so not had chance to verify it - quite worrying if true though!)

 

The validity period isn't that short - more than 2 years. It's more inconvenient than deploying a cert and leaving it for 10 years but then certs should have relatively short validity periods anyway.

 

For context Smoothwall's previous CA issued certificates for 3 years by default so not a gigantic difference in terms of workload.

[Opendium_Steve]

For what its worth, we've done some tests and found that the iOS 13 restrictions on the validity period don't appear to affect CA certificates, only server certificates.

[caffrey]

BYOD is becoming quite untenable isn't it - the amount of time we waste installing these certificates. We've made posters on how to do it but still it's a huge time sink as people just don't get it. I also find that the kids are very suspicious of the certificate (And rightly so) and disable it

Not sure on the future of BYOD

[Opendium_Steve]

BYOD is becoming quite untenable isn't it - the amount of time we waste installing these certificates. We've made posters on how to do it but still it's a huge time sink as people just don't get it. I also find that the kids are very suspicious of the certificate (And rightly so) and disable it

Not sure on the future of BYOD

There's no easy answers. I think that schools have to be open about what the certificates are for, and work with the students and parents, rather than against them - kids are certainly right to be suspicious if they feel that they aren't part of the process. Obviously making them part of the process doesn't solve all of the problems either. There also needs to be an incentive for kids to use the school wifi instead of the mobile network, and I suspect that incentive is being eroded by faster, cheaper mobile networks... (Why use the school's wifi if the mobile network is just as good?)

 

I think the long term will be a combination of network level filtering/monitoring and an on-device agent - things are getting progressively harder to monitor purely on the network side, so I think we'll end up with a hybrid of collecting data from the network and augmenting it with device collected directly from each device, and combining those in clever ways to monitor and filter. But again, its even harder to convince kids to allow an agent to be installed on their device than a certificate! Schools and parents are also going to have to figure out where the boundaries are for online safety responsibility on personal devices - i.e. who should be responsible for:

• Personal devices on the school wifi
  
• Personal devices on school premises but not using the school wifi
  
• Personal devices while not at school
  

Schools obviously don't want to have the responsibility for everything heaped on them, but at the same time they have qualified safeguarding staff and dedicated systems, so should be in a better position than most of the parents. This is all made even harder by the fact that in the rare cases where parents do want to take some responsibility, a lot of on-device parental control software is fundamentally incompatible with most school online safety systems. Not so bad on Android, but iOS parental control software usually tunnels the device's network traffic over a VPN, so completely bypasses the school's systems.

 

Of course, whatever happens with BYOD, you still need to handle school owned tablets, etc. Although they are probably managed by an MDM, the technology is basically the same so everyone still needs to support those devices even if they happen to be school devices instead of BYOD.

[Opendium_Steve]

I should also point out the school's filters are collecting a lot of personal data, and data protection law (GDPR) requires that schools explain that to the kids in understandable terms. So in theory schools are already going some way to being open about this stuff. In practice I'm sure we all know full well that this often doesn't happen!

[caffrey]

Thanks again for being so honest.

We get so many different devices brought in too ranging from Amazon fire tablets to nexus 7s - android is getting more difficult to get on the filtering. The whole thing is hugely frustrating - especially compounded by new changes in new versions of device OS (different instructions for different versions etc.)

I'm fed up of it all ! Our department doesn't get a lot of support from SLT about it either, but I'm going to attempt to draught a document highlighting all the issues.

Edited October 4, 2019 by caffrey

[Opendium_Steve]

We get so many different devices brought in too ranging from Amazon fire tablets to nexus 7s - android is getting more difficult to get on the filtering. The whole thing is hugely frustrating - especially compounded by new changes in new versions of device OS (different instructions for different versions etc.)

 

Android:

Google are clearly opposed to HTTPS decryption, even on MDM devices, and are big enough to basically ignore everyone and do what they want. Luckily it still works for normal web browsing (although we have an unverified report of the very latest Galaxy S10 firmware breaking this, not been able to reproduce this in the lab but don't currently have an S10 available to test with), but they have intentionally broken it across the board for apps and parts of the operating system. There's no sign that they have any intention of fixing this unless some legislation is passed that forces their hand (and no sign of that happening either).

As far as I know, Android has good APIs for parental control software to hook into on the device itself, so there are good prospects for the sort of hybrid systems I mentioned.

 

ChromeOS:

No major problems here as far as I know (there are a few niggles to do with HTTPS decryption of some core operating system stuff, but nothing show-stopping). Obviously there is a concern that this will go the same way as Android at some point in the future.

 

iOS:

No major problems - again, a few niggles with core OS stuff, but Apple aren't obviously opposed to decryption of app traffic in general. Parental control APIs are poor.

 

With all of the tablet/mobile operating systems, there's the problem that the device owner isn't actually in control of their own device - i.e. on the average Android device you don't have permission to do what you like with your device, only Google has that permission; on iOS only Apple has unrestricted access to do what they like with your device. That means we're at the mercy of Google/Apple's whims:

• In 2016, Google decided to break HTTPS decryption for apps, and everyone just had to suck it up.
  
• Earlier this year Apple banned a load of parental control software from the app-store. Again, parents didn't get to make their own decisions about this software, they were just told "no more parental control for you". (This was basically because parental control apps have to rely on Apple's MDM APIs because there is no suitable parental control API, and Apple suddenly decided it wasn't ok to use the MDM APIs for this purpose, even though they provide no alternative).
  
• When combined, DoH/DoT and ESNI are going to make things very difficult. At the moment the end-user is in control of those things, but its reasonable to assume that Google/Apple will force them upon everyone eventually.
  
• In the future, if Google or Apple decide to pull the plug on some API that everyone relies on, there's nothing anyone can do about that.
  

 

I'm a big believer in the device owner being in control of their own device, and we've lost that control - IMHO that's a big problem. I also think that the likes of Google completely miss the distinction between adults and minors: innocent adults absolutely should be protected from snooping governments, etc., but we have "responsible adults" looking after minors for a reason, and you can't be responsible for someone if they have absolute privacy.

I'm fed up of it all ! Our department doesn't get a lot of support from SLT about it either, but I'm going to attempt to draught a document highlighting all the issues.

I'd be interested to see what you come up with, if you're happy for it to be seen outside your school. Obviously we get feedback from our own customers, but its always very interesting to talk to people who are using other systems and find out which problems hit everyone, which are specific to different systems and generally see things from a different perspective!

[caffrey]

Thanks Steve, that provides a good starting point - I just have to translate it for none tech savvy

[michaeljbrewis]

You can downgrade the iPad back to iOS 12.4.1 using iTunes and the relevant IPSW file that can be found here https://ipsw.me/

[ifarmery]

I have added this new certificate and it fixes the ios 13 issue, we still have some old ipad 2's (i know!) that are running ios 9, it appears to not work on these?

[michaeljbrewis]

Yes it works for us now as well since having the new certificates.

[Slum90]

I had this issue last week and we run Netsweeper. Had to change some values for the SSL certificate and this resolved our issue. Didn't have to deploy the certificate or anything again

[mavhc]

Google's been pushing their family control stuff recently.

 

Given devices with cellular data are common, why even distinguish between providing a connection on school wifi and their own connection? If their parents are fine with what they can access via cellular is there a reason to be more restrictive (logically, not lawyery). Anything that's blocked they'll just turn off wifi for. Either you take everyone's devices when they enter school, or you don't, there's no point in a middle ground. BYOD was only ever supposed to be for cheap workplaces, not for schools.