implementación de la capa de registro TLS

Question

implementación de la capa de registro TLS

#1 de dave_thompson_085 (1 votos)

1

Tengo una confusión general sobre el protocolo TLS. Una pregunta es sobre la identificación de la sesión. ¿Debería un ID de sesión dentro del TLS hellomessage tener un campo de longitud de ID de sesión? No leo nada al respecto en la solicitud de comentarios sobre TLS. Si allí un cliente no está reanudando una sesión anterior, entonces dice que debe permanecer "vacío". Qué significa eso? ¿Quizás la longitud de la sesión de identificación (en sí misma un campo de 1 byte) de cero, seguida de un campo sin identificación de sesión? ¿O un campo de id de sesión con cero bytes? ¿O debería eliminar los campos de ID de sesión completamente?

Además, en esta pregunta enlace ¿He recibido las alertas fatales de TLS 70, independientemente de las combinaciones de protocolo que ofrezco? Si invierto el orden de bytes del texto simple, recibo una alerta fatal para 10?

Cualquier ayuda es apreciada.

tls

pregunta marshal craft 13.02.2016 - 09:07

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls

¿Por qué se trunca HMAC en IPsec? ¿Está bien sellar los datos a TPM SRK directamente?

score 1 · Accepted Answer

Hay tres (próximamente cuatro) versiones de TLS, cada una con su propio RFC (más una versión histórica retrospectiva para SSLv3), pero en el nivel de registro básico para los registros no cifrados, es decir, los registros iniciales de reconocimiento a través del primer CCS o alerta - son lo mismo.

RFC5246 para TLSv1.2 en la sección sobre ClientHello se define en la parte superior de la página 41 esa estructura (ClientHello) para incluir SessionID session_id . Del mismo modo, para ServerHello al final de la página 42. Tenga en cuenta que HelloRequest también se clasifica como un mensaje de saludo (y un mensaje de apretón de manos) pero no contiene un session_id o ningún cuerpo. SessionID se define en la página 40 como

opaque SessionID<0..32>;

Debe reconocer esa sintaxis como un vector de longitud variable explicado anteriormente en 4.3 que también explica cómo funciona el prefijo de longitud de cada vector de longitud variable.

'Vacío' significa que no hay bytes en el valor, es decir, una longitud de cero, codificada como un prefijo de longitud de cero seguido de ningún contenido (o de manera equivalente no existe). Si piensa en las codificaciones definidas en la sección 4, es obvio que no puede omitir un campo de una estructura fija; algunos (no todos) los campos de longitud variable pueden estar vacíos, y algunas (solo algunas) estructuras tienen variantes en las que se usan solo los campos de la única variante aplicable en una situación determinada, según se especifique. Sin embargo, el campo de extensión en Cliente o Servidor Hello se define como una secuencia de elementos de longitud variable, cada uno de los cuales comienza con un tipo explícito (2 bytes), por lo que puede incluir u omitir, y reordenar, los elementos de extensión dentro del campo de extensiones - al menos para la codificación; si un par aceptará un conjunto de extensiones depende de ese par.

Si desea implementar TLS, realmente necesita comprender los RFC aplicables para las versiones que desea 2246/4346/5246, además de varios relacionados, como 3546/4366/6066 para extensiones, tal vez 4492 ( y SEC1, etc.) para ECC, tal vez se agreguen suites como 5288/5289 para GCM, etc.