(543) adjust TLS detection regex
See the comments for details. This resolves some of the issues in the
integration tests. Still not sure what changed to cause this to pop up
now.
@@ -182,8 +182,34 @@ typedef unsigned int bool;
// https://tools.ietf.org/html/rfc5246
// http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-tls-session/
// https://tls13.ulfheim.net/
-#define PAYLOAD_BYTESRC 6
-#define PAYLOAD_REGEX "^16030[0-3].{4}0[12]"
+//
+// The definitions below were the original config we were using but during work
+// on #543, we found some cases where the first 6 bytes of the stream were
+// split across two different payloads and doProtocol() is not doing any
+// buffering. TLS detection wasn't working.
+//
+// A little background... The TLS record header is 5 bytes. The header for
+// handshake records starts with 0x16 and, after the remaining 4 bytes of the
+// record header, is followed by a handshake header. The "client hello" and
+// "server hello" handshake headers start with 0x01 and 0x02 respectively. The
+// original regex below is looking for the TLS record header followed by the
+// first byte of either the "client hello" or "server hello" handshake header.
+//
+//#define PAYLOAD_BYTESRC 6
+//#define PAYLOAD_REGEX "^16030[0-3].{4}0[12]"
+//
+// We found that we're only getting the first 5 bytes in one payload to
+// doProtocol() in some cases. It's because the read operation was only for 5
+// bytes or some network fragmentation happened or wonky stream buffering or
+// whatever. In any case, we're changing this to only look for the 5-byte
+// record header and not the handshake header that follows.
+//
+// If you end up here because you're tracking down a partial payload issue in
+// the future, consider adding some buffering of intitial payload data on a
+// channel until you have enough to satisfy TLS and other protocol detection.
+//
+#define PAYLOAD_BYTESRC 5
+#define PAYLOAD_REGEX "^16030[0-3].{4}"
// libmusl requires LD_LIBRARY_PATH
#define LD_LIB_ENV "LD_LIBRARY_PATH"
