¿Cómo funciona SSL trabajo?

Donde está instalado el certificado en el cliente (o el navegador?) y el servidor (o un servidor web?)?

¿Cómo la confianza/de cifrado y la autenticación de inicio del proceso cuando se introduce la URL en el navegador y conseguir que la página desde el servidor?

¿Cómo funciona el protocolo HTTPS reconocer el certificado? ¿Por qué no puede HTTP trabajar con certificados cuando se los certificados que hacer de todo la confianza/de cifrado y la autenticación de trabajo?

  • Creo que esta es una pregunta razonable – la comprensión de cómo funciona el protocolo SSL está en el paso 1, la aplicación correctamente, es el paso 2 hasta el paso infinito.
  • Véase también: security.stackexchange.com/questions/20803/how-does-ssl-work
  • He aquí una buena ejecución a través de https proceso de enlace a nivel de byte
  • No ser una política nazi aquí. Las personas que vienen en busca de ayuda. No negarles la asistencia porque la pregunta no coinciden perfectamente con las reglas.
  • nadie está negando la asistencia. Esto no pertenecen a la Seguridad o de Sysadmin donde es mejor orientadas, pero OP normalmente beneficio en este foro por la adición de algunos bits de programación contexto en lugar de la publicación de un general, SE pregunta. Cuántas personas se preguntas se apague cuando no se encuentran atados a un determinado problema de programación? Probablemente muchos, demasiados, de ahí mi codazos OP para hacer esa asociación.
  • Es sólo a partir de su perfil?
  • y se han malinterpretado un intento de orientación como sarcasmo.
  • No, yo ni siquiera leerlo. Era demasiado larga. Sólo estaba bromeando con usted en el primer lugar de todos modos. Sin resentimientos.

InformationsquelleAutor Vicky | 2009-01-22

4 Comentarios

  1. 137

    Nota: escribí mi respuesta original muy de prisa, pero desde luego, esto se ha convertido en una muy popular de la pregunta/respuesta, por lo que he ampliado un poco y hacerlo más preciso.

    TLS Capacidades

    «SSL» es el nombre que se utiliza más a menudo para referirse a este protocolo, pero SSL se refiere específicamente a la propiedad protocolo diseñado por Netscape en el mediados de los 90. «TLS» es un estándar de la IETF que está basado en SSL, así que voy a usar TLS en mi respuesta. En estos días, las probabilidades son que casi todas tus conexiones seguras en la web realmente están utilizando TLS, SSL.

    TLS tiene varias capacidades:

    1. Cifrar la aplicación de la capa de datos. (En su caso, el protocolo de capa de aplicación es HTTP.)
    2. Autenticar el servidor al cliente.
    3. Autenticar el cliente al servidor.

    #1 y #2 son muy comunes. #3 es menos común. Usted parece estar centrándose en #2, así que voy a explicar esa parte.

    De autenticación

    Un servidor autentica a sí mismo a un cliente a través de un certificado. Un certificado es un blob de datos[1] que contiene información acerca de un sitio web:

    • Nombre de dominio
    • Clave pública
    • La empresa que lo posee
    • Cuando fue emitido
    • Cuando expira
    • Que la emitió
    • Etc.

    Puede lograr confidencialidad (#1) utilizando la clave pública incluida en el certificado para cifrar los mensajes que solo puede descifrarse con la clave privada correspondiente, que deben ser almacenados de forma segura en el servidor.[2] Vamos a llamar a este par de claves KP1, por lo que no vamos a confundir más tarde. Usted también puede verificar que el nombre de dominio en el certificado coincide con el sitio que estás visitando (#2 arriba).

    Pero lo que si un adversario podría modificar los paquetes enviados a y desde el servidor, y lo que si que adversario modificado el certificado que se les presentó y se inserta su propia clave pública o cambiar cualquier otra información importante? Si eso hubiera ocurrido, el adversario puede interceptar y modificar los mensajes que usted pensaba que eran cifrados.

    Para evitar que esta muy ataque, el certificado es criptográficamente firmado por alguien de la clave privada de tal manera que la firma puede ser verificada por cualquiera que tenga la clave pública correspondiente. Vamos a llamar a este par de claves KP2, para que quede claro que estas no son las mismas claves que el servidor está utilizando.

    Autoridades De Certificación

    Así que creó KP2? Quien firmó el certificado?

    Simplificando un poco, un certificado de la autoridad de crea KP2, y los que venden el servicio de uso de su clave privada para firmar certificados para otras organizaciones. Por ejemplo, puedo crear un certificado y tengo que pagar una empresa como Verisign a firmar con su clave privada.[3] Ya que nadie pero Verisign tiene acceso a la clave privada, ninguno de nosotros puede forjar esta firma.

    Y cómo podría yo personalmente me agarra de la clave pública en KP2 con el fin de verificar que la firma?

    Bien ya hemos visto que un certificado puede contener una clave pública y científicos de la computación amor recursividad — entonces, ¿por qué no poner el KP2 clave pública en un certificado, y distribuir esa manera? Esto suena un poco loco al principio, pero en realidad eso es exactamente cómo funciona. Continuando con el ejemplo Verisign Verisign, produce un certificado que incluye información acerca de quiénes son, qué tipos de cosas que se pueden firmar (otros certificados), y su clave pública.

    Ahora si tengo una copia de ese certificado de Verisign, puede utilizarse para validar la firma en el certificado de servidor para el sitio web que desea visitar. Fácil, ¿verdad?!

    Bien, no tan rápido. Tuve que conseguir el certificado de Verisign de en algún lugar. ¿Qué pasa si alguien suplanta el certificado de Verisign y pone su propia clave pública en allí? A continuación, se puede falsificar la firma en el certificado del servidor, y estamos de vuelta donde empezamos: un hombre en el ataque medio.

    Cadenas De Certificados

    Continuando a pensar de forma recursiva, se podría, por supuesto, introducir un tercer certificado y un tercer par de claves (KP3) y el uso que para firmar el certificado Verisign. Llamamos a esto una cadena de certificados: los certificados en la cadena que se utiliza para verificar el certificado siguiente. Esperemos que se puede ver ya que este enfoque recursivo es sólo tortugas/certificados de todo el camino hacia abajo. ¿De dónde parar?

    Ya que no podemos crear un número infinito de certificados, el certificado de la cadena, obviamente, tiene que dejar de en algún lugar, y eso se hace mediante la inclusión de un certificado de la cadena que es auto-firmado.

    Voy a hacer una pausa durante un momento, mientras a recoger los pedazos de la materia cerebral de tu cabeza explote. Auto-firmado?!

    Sí, al final de la cadena de certificados (un.k.una. la «raíz»), habrá un certificado que utiliza su propio par de claves para el signo en sí. Esto elimina la recursividad infinita problema, pero no soluciona el problema de autenticación. Cualquiera puede crear un certificado auto-firmado que dice que nada en ella, como puedo crear un falso Princeton diploma que dice que triple especializó en la política, la física teórica y aplicada culo de patadas y, a continuación, firmar mi nombre en la parte inferior.

    La [algo aburrido] solución a este problema es simplemente para recoger algunos de los certificados auto-firmados de forma explícita la confianza. Por ejemplo, yo podría decir, «yo confianza este Verisign certificado auto-firmado.»

    Con la confianza explícita en su lugar, ahora puedo validar toda la cadena de certificados. No importa cómo muchos certificados que hay en la cadena, podemos validar cada firma todo el camino hasta la raíz. Cuando llego a la raíz, puedo comprobar si dicho certificado raíz es uno de los que me explícitamente confianza. Si es así, entonces puedo confiar en toda la cadena.

    Confiere Confianza

    Autenticación TLS utiliza un sistema de confiere confianza. Si quiero contratar a un mecánico de autos, no puedo confiar en cualquier aleatorios mecánico que me parece. Pero tal vez mi amigo garantiza un particular mecánico. Desde que tengo la confianza de mi amigo, entonces puedo confiar en que el mecánico.

    Al comprar una computadora o descargar un navegador, viene con un par de cientos de certificados raíz que explícitamente fideicomisos.[4] Las empresas que poseen y operan dichos certificados pueden conferir esa confianza a otras organizaciones por la firma de los certificados.

    Esto está lejos de ser un sistema perfecto. Algunas veces una CA puede emitir un certificado erróneamente. En esos casos, el certificado puede necesitar ser revocada. La revocación es complicado ya que el certificado emitido siempre va a ser criptográficamente correcto; un fuera-de-banda protocolo es necesario que previamente certificados que han sido revocados. En la práctica, algunos de estos protocolos no son muy seguros, y muchos de los navegadores no se les echa de todos modos.

    A veces, toda una CA se ve comprometida. Por ejemplo, si usted fuera a romper en Verisign y robar su firma de la raíz de la clave, entonces usted podría suplantar cualquier certificado en el mundo. Observe que esto no solo afecta a los Verisign clientes: incluso si el certificado es firmado por Thawte (un competidor a Verisign), eso no importa. Mi certificado todavía puede ser forjado usando el peligro de clave de firma de Verisign.

    Esto no es sólo teórica. Ha sucedido en la naturaleza. DigiNotar fue célebremente hackeado y, posteriormente, se fue a la bancarrota. Comodo también fue hackeado, pero inexplicablemente siguen en el negocio para este día.

    Incluso cuando CAs no están directamente comprometidos, existen otras amenazas en este sistema. Por ejemplo, un gobierno legal de la coerción para obligar a una entidad emisora de certificados para firmar un forjado certificado. Su empleador puede instalar su propio certificado de CA en su equipo empleado. En estos casos, el tráfico que usted espera estar «seguro» es en realidad completamente visible/modificables para la organización que controla el certificado.

    Algunos reemplazos se han propuesto, incluyendo La convergencia, TACK, y DANE.

    Notas

    [1] certificado TLS datos formateados de acuerdo a la X. 509 estándar. X. 509 se basa en ASN.1 («Notación de Sintaxis Abstracta #1»), lo que significa que es no un formato de datos binario. Por lo tanto, X. 509 debe ser codificado a un formato binario. DER y PEM son los dos más comunes codificaciones, que yo sepa.

    [2] En la práctica, el protocolo en realidad cambia a un algoritmo de cifrado simétrico, pero eso es un detalle que no es relevante a su pregunta.

    [3] Presumible, la CA realmente valida quién eres antes de firmar el certificado. Si no hacen eso, entonces yo podría crear un certificado para google.com y pedir una CA para firmar. Con que certificiate, podía man-in-the-middle cualquier conexión «segura» para google.com. Por lo tanto, el paso de validación es un factor muy importante en el funcionamiento de una entidad emisora de certificados. Por desgracia, no es muy claro cómo este riguroso proceso de validación está en los cientos de CAs en todo el mundo.

    [4] Ver en Mozilla lista de entidades emisoras de confianza.

    • ¿Qué es una clave privada?
    • href=»http://stackoverflow.com/questions/3603714/asymmetric-encryption»>stackoverflow.com/questions/3603714/asymmetric-encryption
    • se le olvidó mencionar que la clave pública es parte del archivo de certificado enviado a la página web para censurar pt los datos servidor está cifrada en el primer lugar.
    • Gracias @mamdouhalramadan. He editado mencionar que.
    • la clave pública es … enviado a la página web para descifrar los datos». ¿Cómo puede la clave pública se utiliza para descifrar los datos?
    • Estás en lo correcto. No se puede. La clave pública sólo se utiliza para la autenticación. La afirmación de aquí que los pares de claves también se utilizan para el cifrado y descifrado es incorrecta. Un negociado de forma segura la clave de sesión se usa para eso.
    • Estás en lo correcto. No se puede. La clave pública sólo se utiliza para la autenticación. La afirmación de aquí que los pares de claves también se utilizan para el cifrado y descifrado es incorrecta. Un negociado de forma segura la clave de sesión se usa para eso.
    • Hay diferentes intercambio de claves de métodos. Por ejemplo, el método RSA el certificado del par de claves de forma segura el intercambio de una clave de sesión, mientras que el DH método utiliza Diffie Hellman para negociar una clave de sesión.
    • El método RSA utiliza el par de claves para transmitir un pre-master secret. NO la clave de sesión. La clave de sesión de negociación después de que se especifica en el RFC 2246 y no depende de la suite de cifrado. La clave de sesión nunca se cifra y nunca se transmite.
    • Bien @EJP estoy un poco perdido, pero siéntase libre de editar mi respuesta, si he dicho algo incorrecto.
    • Siéntase libre de modificar su propia respuesta para la corrección, si se puede, o eliminarla si usted no puede. He proporcionado información suficiente aquí de cualquier manera.

  2. 48

    HTTPS es la combinación de HTTP y SSL(Secure Socket Layer) para proporcionar la comunicación cifrada entre el cliente (navegador) y el servidor web (la aplicación se encuentra aquí).

    Por qué es necesaria?

    HTTPS cifrado de los datos que se transmite desde el navegador al servidor a través de la red. Así, nadie puede oler los datos durante la transmisión.

    Cómo HTTPS se establece la conexión entre el navegador y el servidor web?

    1. Navegador intenta conectarse a la https://payment.com.
    2. payment.com el servidor envía un certificado en el navegador. Este certificado incluye payment.com clave pública del servidor, y algunas pruebas de que la clave pública pertenece en realidad a payment.com.
    3. Navegador verifica el certificado para confirmar que se ha adecuado para el público clave para payment.com.
    4. Navegador selecciona al azar nueva clave simétrica K a utilizar para su conexión a payment.com servidor. Encripta K bajo payment.com clave pública.
    5. payment.com descifra K usando su clave privada. Ahora, tanto el navegador y el servidor de pago sabe K, pero nadie más lo hace.
    6. En cualquier momento navegador quiere enviar algo a payment.com, cifra que en virtud de K; el payment.com servidor descifra a la recepción. En cualquier momento el payment.com servidor quiere enviar algo a su navegador, que lo cifra en virtud de K.

    Este flujo puede ser representado por el siguiente diagrama:
    ¿Cómo funciona SSL realmente funcionan?

    • La parte sobre el cifrado y el envío de la clave de sesión y descodificación en el servidor es completa y absoluta basura. La clave de sesión nunca se transmite a todos: se establece a través de una clave segura negoatiaon algoritmo. Por favor verifique sus datos antes de publicar tonterías como esta. RFC 2246.
    • será mejor si usted podría explicar brevemente acerca de cómo la clave de sesión es establecida……
    • Será mejor si usted lee RFC 2246 whichI ya se han citado. No voy a repetir aquí.
    • Por qué navegador no uso del servidor de claves públicas para cifrar los datos cuando la publiques en el servidor, en lugar de crear una nueva clave simétrica aleatoria K en el paso 4?
  3. 3

    He escrito un pequeño post en el blog que analiza brevemente sobre el proceso. Por favor, siéntase libre para echar un vistazo.

    Protocolo de enlace SSL

    Un pequeño fragmento de la misma es como sigue:

    «Cliente hace una petición al servidor a través de HTTPS. El servidor envía una copia de su certificado SSL + clave pública. Después de verificar la identidad del servidor con su local de CA de confianza de la tienda, el cliente genera una clave para la sesión secreta, se cifra utilizando la clave pública del servidor y envía. Servidor descifra el secreto de la clave de sesión utilizando su clave privada y envía un acuse de recibo al cliente. Canal seguro establecido.»

    • «Después de verificar la identidad del servidor con su local de CA de confianza de la tienda» – esto no es estrictamente cierto. Puedo usar un certificado auto-firmado y HTTPS iba a funcionar – puedo conseguir una conexión HTTPS segura para servidor. El certificado de confianza viene sólo cuando quiero asegurarme de que estoy hablando con el derecho servidor.
    • La parte sobre el cifrado y el envío de la clave de sesión y descodificación en el servidor es completa y absoluta basura. La clave de sesión nunca se transmite a todos: se establece a través de una clave segura negoatiaon algoritmo. Por favor verifique sus datos antes de publicar tonterías como esta. RFC 2246.
    • Eso no es correcto. Certificado de comprobación de confianza es un requisito de la parte de SSL. Se puede omitir, pero normalmente es en efecto: los certificados auto-firmados no funcionan sin medidas especiales de un tipo o de otro.
  4. 0

    Mehaase ha explicado en detalles ya. Voy a agregar a mis 2 centavos a esta serie. Tengo muchos blogposts que giran alrededor de protocolo de enlace SSL y certificados. Mientras que la mayoría de esto gira alrededor de servidor web de IIS, el post sigue siendo relevante para SSL/TLS handshake en general. Aquí están algunas para su referencia:

    No tratar CERTIFICADOS & SSL como un solo tema. Tratarlos como 2 temas diferentes y, a continuación, tratar de ver que trabajan en conjunto. Esto le ayudará a responder a la pregunta.

    El establecimiento de la confianza entre las partes en comunicación a través de Certificado de Tienda de

    La comunicación SSL/TLS funciona únicamente sobre la base de la confianza. Cada ordenador (cliente/servidor) en el internet tiene una lista de la CA Raíz y el Intermedio de la CA que se mantiene. Estos se actualizan periódicamente. Durante el protocolo de enlace SSL se utiliza como referencia para establecer la confianza. Por ejemplo, durante el protocolo de enlace SSL, cuando el cliente proporciona un certificado para el servidor. El servidor intentará cehck si la CA que emitió el certificado está presente en su lista de la CA . Cuando no puede hacer esto, ella declara que fue incapaz de hacer el certificado de la cadena de verificación. (Esta es una parte de la respuesta. También se ve en AIA para esto). El cliente también hace un similar de verificación para el certificado de servidor que se recibe en el Servidor de Hola.
    En Windows, usted puede ver los almacenes de certificados de cliente & Servidor a través de PowerShell. Ejecutar el siguiente desde una consola de PowerShell.

    PS Cert:> ls Ubicación : CurrentUser StoreNames : {TrustedPublisher, ClientAuthIssuer, Raíz, UserDS…}

    Ubicación : LocalMachine StoreNames : {TrustedPublisher,
    ClientAuthIssuer, Escritorio Remoto, Root…}

    Navegadores como Firefox y Opera no se basan en el sistema operativo subyacente para la gestión de los certificados. Ellos mantienen sus propios almacenes de certificados.

    El protocolo de enlace SSL utiliza tanto Simétrica & Criptografía de Clave Pública. Servidor de Autenticación ocurre por defecto. La Autenticación del cliente es opcional y depende de si el extremo del Servidor está configurado para autenticar el cliente o no. Consulte mi blog como lo he explicado esto en detalle.

    Finalmente, para esta pregunta

    ¿Cómo funciona el protocolo HTTPS reconocer el certificado? ¿Por qué no puede HTTP trabajar con certificados cuando se los certificados que hacer de todo la confianza/de cifrado y la autenticación de trabajo?

    Certificados es simplemente un archivo cuyo formato está definido por X. 509 estándar. Es un documento electrónico que acredite la identidad del comunicante.
    HTTPS = HTTP + SSL es un protocolo que define las pautas de cómo 2 partes deben comunicar el uno con el otro.

    MÁS INFORMACIÓN

    • Con el fin de entender los certificados que usted tendrá que entender lo que son los certificados y también leer acerca de la Gestión de los Certificados. Estos es importante.
    • Una vez que se entiende esto, entonces proceder con la negociación TLS/SSL. Usted puede consultar el RFC de la de este. Pero son el esqueleto que definen las directrices. Hay varios blogposts incluyendo la mía que explicar esto en detalle.

    Si la actividad se realiza, entonces usted va a tener una buena comprensión de SSL y los Certificados.

Dejar respuesta

Please enter your comment!
Please enter your name here