¿Qué hace un desarrollador de PHP necesita saber acerca de https / secure socket layer conexiones?

Question

Que no saben nada cuando se trata de el cómo y el porqué de las conexiones https.Obviamente, cuando me voy a la transmisión segura de datos, como contraseñas o, sobre todo, información de tarjeta de crédito, https es una herramienta fundamental.¿Qué necesito saber acerca de ella, aunque?¿Cuáles son los errores más comunes que se puede ver a los desarrolladores de decisiones a la hora de implementarla en sus proyectos?Hay veces cuando https es simplemente una mala idea?Gracias!

Answer 1

Un HTTPS o SSL (Secure Sockets Layer) certificado se sirve de un sitio, y en general es firmado por una Autoridad de certificación (CA), que es, efectivamente, una confianza 3 ª parte que verifica algunos detalles básicos acerca de su sitio, y se certifica para su uso en los navegadores.Si su navegador confía en la CA, a continuación, confía en los certificados firmados por la CA (esto se conoce como la cadena de confianza).

Cada HTTP (o HTTPS) solicitud consta de dos partes:una petición y una respuesta.Cuando solicita algo a través de HTTPS, en realidad, hay un par de cosas que están sucediendo en el fondo:

• El cliente (navegador) hace un "apretón de manos", donde solicita la clave pública del servidor y de la identificación.
  • En este punto, el navegador puede comprobar la validez (no el nombre del sitio el partido?es el rango de la fecha actual?es firmado por una CA de confianza?).Puede incluso contacto con la entidad emisora y asegúrese de que el certificado es válido.
• El cliente crea un nuevo pre-master secret, que se cifra mediante los servidores de claves públicas (de modo que sólo el servidor puede descifrar) y se envía al servidor
• El servidor y el cliente, tanto el uso de este pre-master secret para generar el maestro secreto, el cual es utilizado para crear una clave de sesión simétrica para el intercambio de datos reales
• Ambos lados de enviar un mensaje diciendo que está hecho el apretón de manos
• A continuación, el servidor procesa la solicitud normalmente, y se cifra la respuesta utilizando la clave de sesión

Si la conexión se mantiene abierta, la misma clave simétrica se utiliza para cada uno.

Si una nueva conexión se ha establecido, y ambas partes tienen todavía el maestro secreto, nuevas claves de sesión pueden ser generados en un abreviado apretón de manos'.Normalmente un navegador va a guardar el secreto principal hasta que se cierra, mientras que un servidor se va a almacenar durante un par de minutos o varias horas (dependiendo de la configuración).

Para más información sobre la duración de las sesiones a ver ¿Cuánto tiempo HTTPS clave simétrica pasado?

Certificados y nombres de host

Los certificados se les asigna un Nombre Común (CN), que para HTTPS es el nombre de dominio.El CN tiene que coincidir exactamente, por ejemplo, un certificado con un CN de "example.com" NO va a coincidir con el dominio "www.example.com" y el usuario recibirá una advertencia en su navegador.

Antes de SNI, no fue posible alojar varios nombres de dominio en una dirección IP.Debido a que el certificado se recupera antes de que el cliente incluso envía el real de la petición HTTP, y la petición HTTP que contiene el Host:línea de encabezado que indica el servidor de la URL a usar, no hay manera para que el servidor sepa qué certificado a servir para una solicitud determinada.SNI agrega el nombre de host a una parte de la TLS handshake, y así mientras se apoya en cliente y servidor (y en 2015, es ampliamente admitido), a continuación, el servidor puede elegir el certificado correcto.

Incluso sin SNI, una manera de servir a múltiples nombres de host es con certificados que incluyen Nombres Alternativos del Sujeto (San), que son esencialmente dominios adicionales del certificado es válido para la.Google utiliza un único certificado de seguro muchos sitios, por ejemplo.

Otra forma es utilizar los certificados comodín.Es posible obtener un certificado como ".example.com" en cuyo caso "www.example.com" y "foo.example.com" ambos serán válidas para el certificado.Sin embargo, tenga en cuenta que "example.com" no coincide ".example.com" y tampoco "foo.bar.example.com".Si utiliza "www.example.com" para su certificado, debe redirigir a nadie en "example.com" para el "www." del sitio.Si se solicita https://example.com, a menos que el anfitrión en una IP independiente y tiene dos certificados, la obtendrá un error de certificado.

Por supuesto, usted puede mezclar el comodín y SANs (mientras sus CA le permite hacer esto) y obtener un certificado para ambos "example.com" y con los SANs ".example.com", "example.net", y ".example.net", por ejemplo.

Formas

Estrictamente hablando, si se envía un formulario, no importa si el formulario de la página en sí no está cifrada, mientras el submit URL va a una URL https://.En realidad, los usuarios han sido capacitados (al menos en teoría) no presentar las páginas, salvo que ver a la pequeña "icono de bloqueo", por lo que incluso el propio formulario debe ser servido a través de HTTPS para obtener este.

El tráfico y la Carga del Servidor

El tráfico HTTPS es mucho más grande que la de su equivalente en el tráfico HTTP (debido a la encriptación y certificado de gastos), y también pone más tensión en el servidor (cifrado y descifrado).Si usted tiene un servidor con mucha carga, puede ser deseable que ser muy selectivo acerca de qué contenido se sirve el uso de HTTPS.

Las Mejores Prácticas

• Si usted no es solo el uso de HTTPS para todo el sitio, se debe redirigir automáticamente a HTTPS como sea necesario.Cada vez que un usuario se registra, se debe utilizar HTTPS, y si usted está usando cookies de sesión, la cookie debe tener la seguro bandera conjunto.Esto impide la interceptación de la cookie de sesión, que es especialmente importante dada la popularidad de la apertura (sin cifrar) de las redes wifi.

• Recursos en la página debe venir desde el mismo esquema se utiliza para la página.Si intenta recuperar imágenes de http:// cuando se carga la página con HTTPS, el usuario recibirá una advertencia de seguridad.Usted debe usar completo Url, o de otra forma sencilla es utilizar direcciones Url absolutas que no incluyen el nombre de host (por ejemplo, src="/images/foo.png") debido a que el trabajo de ambos.

  • Esto incluye recursos externos (por ejemplo, Google Analytics)

• No hagas POSTs (formulario envía) al cambiar de HTTPS a HTTP.La mayoría de los navegadores de la bandera esto como una advertencia de seguridad.

Answer 2

Yo no voy a entrar en profundidad en el uso de SSL en general, gregmac hizo un gran trabajo en eso, ve a continuación ;-).

Sin embargo, algunos de los más comunes (y crítica) de los errores cometidos (no específicamente PHP) con respecto a la utilización de SSL/TLS:

1. Permitiendo HTTP cuando deberían estar aplicando HTTPS
2. La recuperación de algunos de los recursos a través de HTTP de una página HTTPS (por ejemplo,imágenes, IFRAMEs, etc)

3. Dirección HTTP de la página de la página HTTPS involuntariamente, tenga en cuenta que esto incluye "falso" de las páginas, tales como "about:blank" (he visto esto como IFRAME marcadores de posición), esto innecesariamente y desagradablemente emergente de una advertencia.

4. Servidor Web configurado para el apoyo de edad, insegura versiones de SSL (por ejemplo,SSL v2 es común, sin embargo, horriblemente roto) (bueno, este no es exactamente el programador del problema, pero a veces nadie más se manejarlo...)

5. Servidor Web configurado para admitir insegura conjuntos de cifrado (he visto NULL sistemas de cifrado sólo en el uso, que básicamente ofrece absolutamente NINGÚN cifrado) (ídem)

6. Los certificados auto-firmados - impide a los usuarios verificar la identidad del sitio.

7. Solicita las credenciales del usuario de la página HTTP, incluso si se envía a una página HTTPS.De nuevo, esto evita que el usuario de la validación de la identidad del servidor ANTES de dar su contraseña...Incluso si la contraseña se transmite encriptada, el usuario no tiene forma de saber si él está en un sitio falso - o incluso si VA a ser cifrados.

8. No cookie segura relacionados con la seguridad de las cookies (como sessionId, token de autenticación, token de acceso, etc.) DEBE se establece con el "seguro" conjunto de atributos.Esto es importante!Si no se establece para garantizar la seguridad de la cookie, por ejemplo,SessionId, puede ser transmitido a través de HTTP (!) - y los atacantes pueden asegurar que esto va a suceder - y permitir así el secuestro de sesión, etc.Mientras estás en ello (aunque esto no está directamente relacionado), establecer el HttpOnly atributo en tus galletas, demasiado (ayuda a mitigar algunos de XSS).

9. Demasiado permisivas de los certificados - dicen que usted tiene varios subdominios, pero no todos ellos están en el mismo nivel de confianza.Por ejemplo, usted tiene www.yourdomain.com, dowload.yourdomain.com y publicaccess.yourdomain.com.Así que usted puede pensar en ir con un certificado wildcard....PERO también tiene secure.yourdomain.com o finance.yourdomain.com - incluso en un servidor diferente.publicaccess.yourdomain.com entonces será capaz de suplantar a secure.yourdomain.com....Aunque puede haber casos en los que esto es bueno, por lo general, usted querrá algunos de separación de privilegios...

Eso es todo lo que puedo recordar ahora, podría volver a editar más adelante...

Tan lejos como cuando es una MALA idea para utilizar SSL/TLS - si usted tiene información pública que NO está destinado a un público específico (un único usuario o a los miembros registrados), Y no está determinado acerca de ellos recuperar específicamente de la fuente apropiada (por ejemplo,cotización de los valores DEBE venir de una autentica fuente...), entonces no hay ninguna razón real para incurrir en los gastos generales (y no sólo el rendimiento...dev/prueba/cert/etc).

Sin embargo, si usted tiene los recursos compartidos (por ejemplo,mismo servidor) entre su página web y otra MÁS SENSIBLES sitio, el más sensible sitio debe ser el establecimiento de las reglas aquí.

Además, las contraseñas (y otras credenciales), información de tarjeta de crédito, etc debe ser SIEMPRE a través de SSL/TLS.

Answer 3

Asegúrese de que, cuando en una página HTTPS, todos los elementos en la página web provienen de una dirección HTTPS.Esto significa que los elementos deben tener rutas relativas (por ejemplo,"/images/banner.jpg para que el protocolo es una enfermedad hereditaria, o que usted necesita para hacer una verificación en cada página para encontrar el protocolo, y el uso que de todos los elementos.

NB:Esto incluye todos los recursos externos (como Google Analytics archivos javascript)!

El único lado negativo que puedo pensar es que se añade (casi despreciable) tiempo de procesamiento para el navegador y el servidor.Yo sugeriría cifrar sólo las transferencias que se necesita para ser.

Answer 4

Yo diría que la mayoría de los errores comunes cuando se trabaja con un sitio con SSL son

1. El sitio erróneamente redirige a los usuarios a http de una página https
2. El sitio no cambia automáticamente a https cuando es necesario
3. Imágenes y otros activos en una página https se carga a través de http, de modo que se active una alerta de seguridad en el navegador.Asegúrese de que todos los activos están utilizando completo URIs que especificar https.
4. El certificado de seguridad sólo funciona para un subdominio (como www), pero su sitio en realidad usos múltiples subdominios.Asegúrese de obtener un certificado comodín, si usted lo necesita.

Answer 5

Yo sugeriría cualquier momento cualquier los datos del usuario se almacenan en una base de datos y comunicar, usar https.Considere la posibilidad de este requisito, incluso si los datos de usuario es mundano, porque incluso muchos de estos detalles mundanos son utilizados por el usuario para identificarse en otros sitios web.Considerar todas las aleatoria de las preguntas de seguridad de su banco le pide a usted (como en qué calle vives en?).Esto puede ser tomado de los campos de dirección muy fácilmente.En este caso, los datos no es lo que se considera una contraseña, pero bien podría ser.Además, nunca se puede anticipar lo que los datos de usuario se puede utilizar para una pregunta de seguridad en otros lugares.También se puede esperar que con la inteligencia de que el promedio de usuario de la web (creo que tu abuela) que ese dato de la información que podría hacer parte de la contraseña del usuario en algún otro lugar.

Un puntero si se utiliza https

hacerlo de modo que si el usuario escribe http://www.website-that-needs-https.com/etc/yadda.php automáticamente se redirige a https://www.website-that-needs-https.com/etc/yadda.php personal (quejas)

Sin embargo, si usted está haciendo una simple página html, que será esencialmente una forma de transmisión de información desde el servidor hacia el usuario, no te preocupes.

Answer 6

Muy buena sugerencia aquí...pero quiero agregar algo..
He visto algunos sitios que le da un http página de inicio de sesión y sólo redirigir a https después de la publicación de su nombre de usuario/pass..Esto significa que el nombre de usuario que se transmite en el claro antes de la conexión https es establecido..

En definitiva hacen que la página de inicio de sesión de ssl, en lugar de la publicación en un ssl página.

Answer 7

He encontrado que tratando de <link> a un inexistente hoja de estilo también provocó advertencias de seguridad.Cuando he utilizado la ruta de acceso correcta, el icono de bloqueo apareció.