In order to get my personal phone onto the Wi-Fi network at my workplace, I have to accept a certificate:
If I accept this certificate, will I be vulnerable to man-in-the-middle attacks? For example, if my corporate IT department decided to issue their own SSL certificate for www.google.com, would my device think that that certificate was valid?
What is this certificate being used for?
What is this certificate being used for?
A standard implementation of WPA or WPA2 in enterprise environments is to use certificate-based authentication for wireless network access. For company-owned devices, it makes connecting to a company wireless network seamless - the required certificates are automatically installed at some point (during imaging/provisioning, via Group Policy, etc.), completely transparently to the end user. When a user goes to connect to a wireless network with their company-owned device, it already has the required certificate installed and trusted. (Depending on the configuration, the certificate alone may be enough, or it may require additional authentication in the way of domain credentials, or be based on the device itself, etc.)
If I accept this certificate, will I be vulnerable to man-in-the-middle attacks?
Probably not.
The certificates in question for WPA-enterprise are usually generated by an internal certificate authority, rather than a public certificate authority, which means that personal devices don't trust the CA, because they don't know about it. The OEM of your device (Apple) preloads it with a list of trusted public CAs which provide certificates for public-facing services (https websites being the most ubiquitous example), but as your employer's wireless network is not public-facing, there's no reason for them to use such a certificate (and arguably, a few reasons for them not to).
For this reason, your device is prompting you with a warning that you're being offered a certificate from an untrusted/unverified source.
If you look at the certificate, it says the purpose is "Server Authentication." This indicates that the certificate is being used to authenticate a particular server on your company's network (either the WAP you're connecting to, or the RADIUS server that's doing Authentication, Authorization and Accounting (AAA) for wireless connections). Accepting this certificate will only make your device trust the server that the certificate is for. If your IT department decided to issue a cert for Google or whomever to intercept SSL traffic, your device would not automatically trust that certificate based on accepting this one, because this certificate is only used to authenticate a specific host. In order to do that, you would have to accept a certificate from the internal certificate authority.
That being said, there is a very remote possibility that you're actually connecting to a rogue WAP that's only claiming to be one of your employer's. To determine whether the AP you're connecting to is legitimate or not, you'd probably want to ask your IT department. You could compare the certificate with one you know is valid (such as one that's installed on your company-owned device), or import the public certificate from your company's internal CA onto your personal device, but it's generally easier to just ask. (And if you're worried about your employer intercepting SSL traffic, you wouldn't want to import any internal CA certificates onto your device, of course.)
In this case, no, your device will not be subject to MITM of https traffic.
It is possible for employers to deploy a root certificate to machines in order to install a MITM proxy. (BlueCoat is a company that offers such a device commercially.) However, that requires a "trusted root" certificate to be installed in the client computers.
In your case, the certificate pictured in your screen shot says it will be used for "server authentication." This is not a trusted root certificate, and cannot be used to verify other certificates. This means a MITM proxy won't be able to use it to give you a substitute signed certificate.
Of course, your unencrypted traffic is still subject to inspection.
I assume that you are connecting from your personal device.
Many companies have their own certificates on their network somewhere in order for them to check HTTPS traffic going through their network. In many countries it is legal for companies to read traffic using their equipment, and they find this necessary to protect against viruses etc.
As they can't read the HTTPS, they give you their own certificate and then re-encrypt the data between them and your destination. A MITM indeed, but it is only your company, and presumably you can trust them.
It is not possible for anybody else to perform a MITM attack if you only accept the certificate from your company.
This is the equivalent of creating a self-signed certificate. Imagine the following, you deploy a network. Inside of this network are systems you know you deployed, and trust. You create a self-signed certificate with strong encryption. This certificate cannot be validated by yourself unless you create your own Certificate Authority (CA).
What you are seeing: "Not Verified" simply means that this certificate is not visible to any CA. Your company has some choices: 1) Get a signed certificate 2) Create their own CA or 3) leave it as is. So it is left as is, and now you are getting the error. Are you vulnerable to a MiTM attack? The answer is, yes. But even with a signed certificate you are vulnerable to a MiTM attack.
Attackers have been known to steal legitimate SSL certificates, so you are vulnerable to a MiTM attack with or without a verified certificate, however it is easier to perform a MiTM attack with an unverified certificate since users are apt to just hit "OK" when they are prompted with "This certificate is not valid." Here is some informative reading on SSL to further answer your question.
yes you will be: it seems that a MITM is planting a cert in your device. Can you show a full certificate details? What are it's permitted usage capabilities? If it would be a valid internal certificate for - let's say - an intranet web interface to something - then no external name(like dot-com as I see on your screenshot) will ever be in the cert info
