I have some general confusion about TLS protocol. One question is about session id. Should a session id inside the TLS hellomessage have a session id length field? I do not read anything about it in the request for comments on TLS. If there a client is not resuming a prior session then it says it should remain 'empty'. What does that mean? Perhaps id session length (itself a 1 byte field) of zero, followed by no session id field? Or a session id field with zero byte? Or should I remove the session id fields completely?

Additionally in this question https://stackoverflow.com/questions/35361617/how-to-format-a-tls-record-to-be-sent-with-winsock-for-https I have received TLS fatal alerts 70, regardless of the protocol combinations I offer? If I reverse the byte ordering of the plain text I get a fatal alert for 10?

Any help is appreciated.


There are three (soon four) versions of TLS, each with its own RFC (plus a retrospective historical one for SSLv3), but at the basic record level for unencrypted records -- which is, initial handshake records through first CCS or alert -- they are the same.

RFC5246 for TLSv1.2 in the section on ClientHello defines at the top of page 41 that structure (ClientHello) to include SessionID session_id. Similarly for ServerHello at the bottom of page 42. Note that HelloRequest is also classified as a hello message (and a handshake message) but does not contain a session_id or indeed any body at all. SessionID is defined on page 40 as

opaque SessionID<0..32>;

You should recognize that syntax as a variable-length vector previously explained in 4.3 which also explains how the length prefix of every variable-length vector works.

'Empty' means no bytes in the value i.e. a length of zero, encoded as a length prefix of zero followed by no (or equivalently not any) content. If you think about the encodings defined in section 4 it is obvious that you cannot omit a field from a fixed structure; some (not all) variable-length fields can be empty, and some (only some) structures have variants where you use only the fields of the one variant applicable in a given situation as specified. However, the extension field in Client or Server Hello is defined as a variable-length sequence of items each of which begins with an explicit (2-byte) type, so you can include or omit, and reorder, extension items within the extensions field -- at least for encoding; whether a peer will accept a set of extensions is up to that peer.

If you want to implement TLS you really need to understand the applicable RFC(s) for the version(s) you want 2246/4346/5246, plus several related ones like 3546/4366/6066 for extensions, maybe 4492 (and SEC1 etc) for ECC, maybe added suites like 5288/5289 for GCM, etc.

  • Are parts of the record encoded in ascii or simply as numbers? Feb 17 '16 at 11:47
  • @marshalcraft A generic record (headers) no. The optional extensions in ClientHello and ServerHello include Server Name Indication (SNI) which contains DNS name(s) which are a subset of ASCII defined by DNS standards, and Application Layer Protocol Negotiation (ALPN) which contains names that are formally opaque but all actually registered names are short ASCII strings. Feb 18 '16 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.