La autenticación del certificado SSL del cliente sería algo que podría considerar. En lugar de proporcionar credenciales, su servidor le solicitará que proporcione un certificado (que puede incrustar en su aplicación).
Una pequeña descripción general que obtuve de Wikipedia :
El siguiente ejemplo completo muestra cómo se autentica un cliente (en
Además del servidor como arriba) vía TLS usando certificados
Intercambiaron entre ambos compañeros.
Fase de negociación:
- Un cliente envía un mensaje de ClientHello que especifica la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de sugerencias sugeridas.
conjuntos de cifrado y métodos de compresión.
- El servidor responde con un mensaje de ServerHello, que contiene la versión del protocolo elegido, un número aleatorio, un conjunto de cifrado y
Método de compresión a partir de las opciones ofrecidas por el cliente. los
El servidor también puede enviar un ID de sesión como parte del mensaje para realizar
un apretón de manos reanudado.
- El servidor envía su mensaje de certificado (según el paquete de cifrado seleccionado, el servidor puede omitirlo).
- El servidor solicita un certificado del cliente, para que la conexión pueda autenticarse mutuamente, utilizando un CertificateRequest
mensaje.
- El servidor envía un mensaje de ServerHelloDone, que indica que se realizó con la negociación de intercambio.
- El cliente responde con un mensaje de certificado, que contiene el certificado del cliente.
- El cliente envía un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, una clave pública o nada. (De nuevo, esto depende de la
cifrado seleccionado.) Este PreMasterSecret se encripta usando el comando público
clave del certificado del servidor.
- El cliente envía un mensaje de CertificateVerify, que es una firma sobre los mensajes de intercambio anteriores utilizando los certificados del cliente.
llave privada. Esta firma puede ser verificada mediante el uso del cliente.
Clave pública del certificado. Esto le permite al servidor saber que el cliente
tiene acceso a la clave privada del certificado y, por lo tanto, posee la
certificado. El cliente y el servidor luego usan los números aleatorios y
PreMasterSecret para calcular un secreto común, llamado "maestro
secreto ". Todos los demás datos clave para esta conexión se derivan de esta
maestro secreto (y los valores aleatorios generados por el cliente y el servidor),
que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
- El cliente ahora envía un registro ChangeCipherSpec, que básicamente le dice al servidor: "Todo lo que le diga a partir de ahora será autenticado
(y cifrado si el cifrado fue negociado). "The ChangeCipherSpec
es en sí mismo un protocolo de nivel de registro y tiene tipo 20 y no 22.
Finalmente, el cliente envía un mensaje finalizado encriptado, que contiene un
hash y MAC en los mensajes de intercambio anteriores.
- El servidor intentará descifrar el mensaje finalizado del cliente y verificar el hash y el MAC. Si el descifrado o verificación
falla, el apretón de manos se considera que ha fallado y el
la conexión debe ser demolida.
- Finalmente, el servidor envía un ChangeCipherSpec, que le dice al cliente, "Todo lo que le diga a partir de ahora será autenticado (y
cifrado si el cifrado fue negociado). "El servidor envía su propio servidor.
mensaje terminado encriptado.
- El cliente realiza el mismo descifrado y verificación.
fase de solicitud:
- En este punto, el "apretón de manos" está completo y el protocolo de la aplicación está habilitado, con un tipo de contenido de 23. Mensajes de la aplicación
El intercambio entre el cliente y el servidor también se cifrará exactamente
como en su mensaje finalizado.