15

There is a lot of confusion around this on here, so I am making this post to be sure to understand it correctly. My school uses Aruba networks wifi, and after I type my Active Directory username and password (RADIUS authentication), it tells me I have to trust a certificate from 'wifiaruba.myschoolname.com' (Organization: My School) issued by DigiCert SHA2 High Assurance Server CA (Issuer Name, at least that is what the certificate says). I click trust and it goes away. My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications? If it really were from DigiCert, surely my phone would trust it?

Laurel
  • 129
  • 7
BusinessGuy
  • 153
  • 1
  • 1
  • 4

3 Answers3

22

It's ok. The certificate you installed and trusted is used to provide you secure authentication against their RADIUS server and prevent you from connecting to rogue RADIUS server. If someone decides to steal your Active Directory credentials by installing a rogue RADIUS server your phone will pop up with a warning that RADIUS certificate is not trusted.

By trusting this certificate you are not risking with anything else. This certificate can't be used by school to read your SSL traffic or attempt to MITM your SSL traffic. From what I read in your question, your school does it correctly and cares about your security.

Regarding your question: why your phone does not trust that certificate (which is certainly issued by trusted authority). RADIUS requires explicit trust to particular RADIUS authentication certificate, because you don't know what AP you are connecting to. Otherwise, an attacker could get certificate from other trusted CA vendor (say, Let's Encrypt) and use it to impersonate school RADIUS server and steal your credentials.

This is not an issue in SSL context, because you know what kind of certificate you expect, because you manually type web site name in address bar. In wi-fi don't know to which AP you are connected and to ensure that it is legitimate, AP should provide RADIUS certificate you explicitly trust.

Crypt32
  • 5,750
  • 12
  • 24
  • Two things, 1) The reason that the phone doesn't trust the Cert is probably because it'd signed by an Internal CA Managed by DigitCert, and since you don't have that issuer in your trusted connections yet, hence the ask. 2) This still doesn't prevent the school from MITIMing you. Network traffic could run through an SS/TLSL proxy and handle the interaction between the client and the Server. – Shane Andrie Feb 01 '18 at 18:01
  • 1
    "DigiCert SHA2 High Assurance Server CA" is not used in managed PKI scenarios. It is standard SSL CA server. Therefore it is not possible to MITM students. I explained in my answer why phone doesn't trust RADIUS cert even though CA is trusted. – Crypt32 Feb 01 '18 at 18:03
  • Could the issuer name be theoretically falsified by the school? – BusinessGuy Feb 01 '18 at 18:18
  • 1
    If you are not asked to install Root certificate, then no, school cannot do that. – Crypt32 Feb 01 '18 at 19:05
4

My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications?

Based on your description no it does not.

If it really were from DigiCert, surely my phone would trust it?

The problem is that before you authenticate to the wireless network, you are not actually connected to the network and can't reach any other host. When your device attempts to authenticate, the EAP supplicant on your phone will only be communicating with the authentication server.

With most EAP methods used by 802.11 wireless, the server will present a certificate to the EAP supplicant and the supplicant must make a decision if it will pass your credentials (username/password) back to the server. Since your device isn't yet connected to the network, the EAP supplicant is working with limited knowledge.

At the minimum, unless certificate validation is disabled, the EAP supplicant will check that the certificate is a valid certificate issued from a trusted CA and that the hostname listed on the certificate matches the hostname of the authentication server.

With some EAP supplicants, you can also optionally configure a designated CA(s) as the issuer of the certificate (i.e. only from Thawte or Digicert) and/or specific hostnames for the authentication servers. Many mobile devices (phones, tablets, etc) do not have these options.

Without use those options or some other sort of check, your phone would automatically accept any authentication server that would provide a valid certificate with a matching hostname. This would make it easy for an attacker to impersonate your school's wireless network and capture credentials on their own "authentication server." The prompt for you to accept the certificate is your chance to approve or reject sending your credentials to the authentication server.

Once you have accepted the certificate the first time, you should only ever see the prompt again if your phone is presented a different certificate (or you delete and re-add the wireless profile). Some schools will have multiple authentication servers so it isn't unusual to see this multiple times. However if you ever find a certificate suspicious (i.e. "arubuwifi.jimbobscomputers.com"), you should not accept it.

YLearn
  • 3,967
  • 1
  • 17
  • 34
-8

NO THIS IS NOT OK AND IT'S WEIRD THAT PEOPLE ARE SAYING IT IS!

When it says "not trusted", that means that your phone could not verify the certificate. Unfortunately, an iPhone does not tell you why it can't verify it. It is possible that there is an attacker who signed their own certificate (it is very easy to do this on any computer) and simply forged the names of your school and of DigiCert etc. While it is not feasible to forge a signature for one of, say, DigiCert's real keys, it is possible to simply put in a garbage signature or fake DigiCert key; the iPhone won't be able to verify it and will simply say "not trusted".

So what could an attacker do if they had you trust their certificate? Well, if they get you to accept a signing certificate, then yes, they could inspect all of your SSL/TLS traffic. This is what censoring nation-states do to spy on their citizens' traffic.

If it says "not trusted" then do not trust it. Everyone else is giving you horrible advice and false information.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
Dave Levin
  • 1
  • 2
    The upvoted answer clearly explains why it is fine in this context and that this context is not about SSL. Also, the link to your own web site does not belong in this answer (removed). You can have such link in your profile though. – Steffen Ullrich Oct 24 '19 at 17:16
  • 1
    The question was by the OS on whether to trust the SSL cert. It is not asking them to install a new CA certificate, so it is unlikely that it could be used to inspect their SSL/TLS traffic (a certificate alone won't allow that, it needs to be installed as a CA certificate). As I explain in my answer, there is no way for a EAP supplicant to fully validate the certificate with the CA prior to completing the authentication to the network. The EAP supplicant should only prompt the user to accept an unknown valid certificate, it should not accept/prompt if the certificate is invalid in some form. – YLearn Oct 24 '19 at 19:24