Cuál es la respuesta HTTP adecuada para enviar para las solicitudes que requieren SSL/TLS

Estoy diseñando una API RESTful donde algunas llamadas son públicas a través de HTTP, y algunas requieren una clave API y cifrado a través de HTTPS. Estoy deliberando sobre qué código de respuesta se debe enviar si se envía una solicitud HTTP a uno de los recursos privados. Hasta ahora, el único que salta a la vista es 412 - Falló la condición previa, pero la norma indica que la condición previa es impuesta por el solicitante, no por el servidor.Cuál es la respuesta HTTP adecuada para enviar para las solicitudes que requieren SSL/TLS

¿Hay un código de respuesta adecuado para esta condición o solo tengo que ceder y hacer ?

Fuente

2010-03-31 gtd

La manera más segura para forzar cliente HTTP a utilizar HTTPS es HTTP Strict Transport Security.

Anteriormente, una sugerencia común era soltar la conexión, pero este practice has been removed in favor of HSTS (sitio web OWASP).

Fuente

2014-01-31 17:03:52

Gracias por la actualización. – gtd

1. El borrador de HSTS ha sido [movido a IETF] (http://tools.ietf.org/id/draft-ietf-websec-strict-transport-sec). 2. leerlo en realidad no da una buena respuesta a la pregunta del OP. –

HSTS impone HTTPS en el sitio completo . El póster anterior quería que algunos recursos estuvieran disponibles a través de HTTP, mientras que otros solo a través de HTTPS. Por lo tanto, no se puede usar HSTS ya que se aplica a todos los recursos. – Fred

El código de error apropiado para devolver sería similar a 403.4 - SSL required.

Aunque no explícitamente documentada en el RFC for HTTP 1.1, este comportamiento no coinciden con los requisitos expuestos en la misma:

El servidor ha entendido la solicitud, pero se niega a cumplirlo. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no era HEAD y el servidor desea hacer público el motivo por el cual no se ha cumplido la solicitud, DEBERÍA describir el motivo de la negativa en la entidad. Si el servidor no desea poner esta información a disposición del cliente, se puede usar el código de estado 404 (No encontrado).

Agregar su propio subcódigo (como con el ejemplo SSL) podría ser útil en algunos casos, pero dado que este subcódigo no sería significativo para terceros, recomendaría que no lo haga.

Por lo tanto, su mensaje de error final sería algo así como "403 - Recurso privado". Tenga en cuenta que, incluso en el caso de que falte una clave de API, no se debe usar "401 - No autorizado", a menos que su clave de API realmente se pueda transmitir en un campo de encabezado WWW-Authenticate.

Fuente

2010-03-31 16:53:41 mdb

Tenga en cuenta que los códigos de estado de IIS son falsos. Los códigos de estado HTTP están compuestos de números solamente (3 exactamente). Ver http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 También tenga en cuenta que la frase de razón para 403 es "Prohibida" y que esto no está sujeto a modificaciones. Cualquier explicación adicional debe ir a la respuesta * cuerpo *. –

Sí, tan atractivo como ese subcódigo es que no puedo estar detrás de la naturaleza no estandarizada de él. – gtd

Estoy de acuerdo con otros comentaristas en que no se debe usar un subcódigo, pero podría hacerse un caso para un 403 normal. Por ejemplo, eso es lo que Twitter está usando para su API. Ver https://dev.twitter.com/docs/security/using-ssl –

No puedo decir si esto es ampliamente aceptado por los clientes HTTP, pero hablando estrictamente RFC, el servidor debe responder con:

HTTP/1.1 426 Upgrade Required 
Upgrade: TLS/1.0, HTTP/1.1 
Connection: Upgrade

Fuente:
http://tools.ietf.org/html/rfc2817#section-4.2

Fuente

2010-03-31 20:06:54 MicE

Interesante. RFC y OWASP difieren en sus recomendaciones. Prefiero la versión de OWASP: no responda a la solicitud y simplemente deje caer el paquete. Con el enfoque de RFC, un hombre en el medio podría interceptar la respuesta (ya que no es https todavía) y redirigir a un sitio web falso. –

Sí, estoy de acuerdo, definitivamente es una vulnerabilidad. Incluso si abandonar la conexión puede ser confuso, las preocupaciones de seguridad deberían tener prioridad aquí. Además, tenga en cuenta que el RFC mencionado tiene ahora prácticamente 10 años (en esos momentos, la seguridad podría no haber sido un aspecto tan importante como lo es hoy). – MicE

Ya sabes, después de mirar más de cerca me di cuenta de que esto es para una actualización a TLS, presumiblemente de una versión anterior de SSL. No estoy haciendo TLS, así que no puedo usar ese encabezado, y dado que la especificación es específicamente para TLS, no creo que sea apropiado. Lamentablemente, tampoco tengo una forma de soltar la conexión ... – gtd

acaba de enviar una redirección a la correspondiente https: URI.

ACTUALIZACIÓN

El es una respuesta equivocada - ver comentarios abajo

Fuente

2010-03-31 21:21:48

Existe un riesgo de seguridad. "Un atacante que realiza un ataque de hombre en el medio podría interceptar la respuesta de redireccionamiento HTTP y enviar al usuario a una página alternativa" - de OWASP SSL Best Practices –

Eso no impide que los usuarios sigan refiriéndose a la url http, de hecho, con la mayoría clientes http que ni siquiera verán que se realizó una redirección http. Barrido del problema debajo de la alfombra probablemente no sea el enfoque que desea tomar. –

Sí, lo siento. Ustedes tienen razón Enviar una redirección es lo incorrecto. Gracias por señalar eso. –

Devolución de una con la razón frase "HTTPS necesario" parece una opción práctica y lo que yo uso.

ver https://en.wikipedia.org/wiki/HTTP_403

a redirigir una API REST no es una buena idea, especialmente ya que puede tener ni idea de cómo o por qué está consumiendo su servicio.

Fuente

2016-01-20 11:57:23 NER1808

Cuál es la respuesta HTTP adecuada para enviar para las solicitudes que requieren SSL/TLS

Respuesta

Cuestiones relacionadas