El wifi de mi escuela pide "confiar" en un certificado de Iphone, ¿esto les permite ver el tráfico SSL?

Está bien. El certificado que instaló y de confianza se utiliza para proporcionarle una autenticación segura contra su servidor RADIUS y evitar que se conecte a un servidor RADIUS malicioso. Si alguien decide robar sus credenciales de Active Directory instalando un servidor RADIUS no autorizado, su teléfono mostrará una advertencia de que el certificado RADIUS no es confiable.

Al confiar en este certificado, no está arriesgando nada más. La escuela no puede usar este certificado para leer su tráfico SSL o intentar MITM su tráfico SSL. Por lo que leí en tu pregunta, tu escuela lo hace correctamente y se preocupa por tu seguridad.

Con respecto a su pregunta: por qué su teléfono no confía en ese certificado (que ciertamente es emitido por una autoridad confiable). RADIUS requiere una confianza explícita en un certificado de autenticación RADIUS particular, porque no sabe a qué AP se está conectando. De lo contrario, un atacante podría obtener un certificado de otro proveedor de CA de confianza (por ejemplo, Let's Encrypt) y usarlo para suplantar el servidor RADIUS de la escuela y robar sus credenciales.

Esto no es un problema en el contexto SSL, porque sabe qué tipo de certificado espera, ya que escribe manualmente el nombre del sitio web en la barra de direcciones. En wi-fi no sabemos a qué AP está conectado y para asegurarse de que sea legítimo, AP debe proporcionar un certificado RADIUS en el que confíe explícitamente.

    

  

Parece que mi teléfono no confía en esto de forma predeterminada. ¿Es porque esto teóricamente permite que mi escuela descifre las comunicaciones SSL?

Según su descripción, no, no.

  

Si realmente fuera de DigiCert, seguramente mi teléfono confiaría en ello.

El problema es que antes de autenticarse en la red inalámbrica, no está realmente conectado a la red y no puede comunicarse con ningún otro host. Cuando su dispositivo intente autenticarse, el suplicante EAP de su teléfono solo se comunicará con el servidor de autenticación.

Con la mayoría de los métodos EAP utilizados por la tecnología inalámbrica 802.11, el servidor presentará un certificado al suplicante de EAP y el suplicante debe tomar una decisión si pasará sus credenciales (nombre de usuario / contraseña) de vuelta al servidor. Dado que su dispositivo aún no está conectado a la red, el suplicante de EAP está trabajando con un conocimiento limitado.

Como mínimo, a menos que la validación del certificado esté deshabilitada, el solicitante EAP verificará que el certificado sea un certificado válido emitido por una CA de confianza y que el nombre de host que figura en el certificado coincida con el nombre de host del servidor de autenticación.

Con algunos suplicantes de EAP, también puede configurar opcionalmente una (s) CA designada (s) como el emisor del certificado (es decir, solo de Thawte o Digicert) y / o nombres de host específicos para los servidores de autenticación. Muchos dispositivos móviles (teléfonos, tabletas, etc.) no tienen estas opciones.

Sin usar esas opciones o algún otro tipo de verificación, su teléfono aceptaría automáticamente cualquier servidor de autenticación que proporcione un certificado válido con un nombre de host correspondiente. Esto facilitaría a un atacante hacerse pasar por la red inalámbrica de su escuela y capturar credenciales en su propio "servidor de autenticación". La solicitud para que acepte el certificado es su oportunidad de aprobar o rechazar el envío de sus credenciales al servidor de autenticación.

Una vez que haya aceptado el certificado la primera vez, solo debería volver a ver el aviso si su teléfono presenta un certificado diferente (o si elimina y vuelve a agregar el perfil inalámbrico). Algunas escuelas tendrán múltiples servidores de autenticación, por lo que no es raro ver esto varias veces. Sin embargo, si alguna vez encuentra un certificado sospechoso (es decir, "arubuwifi.jimbobscomputers.com"), no debe aceptarlo.