> Next to this we would want to record TLS/SSL details that are not clear from > the above WARC record with HTTP response. We could certainly store an > abstraction or interpretation of these details, but we risk losing > information if we do (similar to how we store the raw HTTP response without > alterations). From my initial message, an example TLS record may look like > (with fake digest and length, copied from the HTTP WARC record example):
Again, think carefully about the data you are recording. Also, TLS1.2 allows renegotiation in an active connection to do things like change the cipher algorithm, ask the client to send its certificate, and so on. Are you going to record those? Client authentication seems like something important. And which part are you recording". The client or server side or both? You said "outgoing TLS record" but that's not clear to me. Renegotiation can be initiated by either side FYI. > The handshake messages hold interesting data, for example they could be used > for fingerprinting and in that way affect the HTTP responses. These message > are on the TLS level layer. We would want to store these as they are received > so as to not risk losing any information, as we do for the HTTP level layer. Are you going to support session resumption, session tickets, pre-shared keys? Are you going to ensure your client doesn't do any of those? Merging the thread this early didn't help this conversation. I am sure I have missed replying to some of my points that you responded to. I read RFC 7595 and looked at the IANA registry. I am fairly confident that you will never get the "tls" scheme, so you might want to re-think things a bit. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
