Support for false start /early data in TLS 1.2 about tlse HOT 6 CLOSED

On Sat, Mar 2, 2019 at 4:39 AM Eduard Suica ***@***.***> wrote: Compile with -DTLS_12_FALSE_START. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AScbLuALygUPTkedxhmU6umShUurmLaKks5vSnEKgaJpZM4baAg2> .

On Sat, Mar 2, 2019 at 10:43 PM Eduard Suica ***@***.***> wrote: Hello, TLSe is transport-layer agnostic. I try to keep a logical separation between socket I/O and TLS layer. The only exception is kTLS. For example: while ((read_size = recv(sockfd, client_message, sizeof(client_message) , 0)) > 0) { tls_consume_stream(context, client_message, read_size, validate_certificate); ... } And: unsigned int out_buffer_len = 0; const unsigned char *out_buffer = tls_get_write_buffer(context, &out_buffer_len); ... int res = send(client_sock, (char *)out_buffer, out_buffer_len, 0); ... tls_buffer_clear(context); } This code should be in your client application (not inside TLSe). You're free to use any flags you would like. For TCP fast open+ TLS you should do something like this: tls_sni_set(context, "hostname"); tls_client_connect(context) connect(sockfd, ...) // do your TCP-related stuff here tls_get_write_buffer(context, ...); send(...) or sendmsg(...) or anything you would like until write buffer is empty Also, you may add a function like this: const unsigned char *tls_reown_write_buffer(struct TLSContext *context, unsigned int *outlen) { .. *outlen = context->tls_buffer_len; const unsigned char *buffer = context->tls_buffer; context->tls_buffer = NULL; context->tls_buffer_len = 0; return buffer; } This should answer point 1 and 3. For point 2, I'm not sure if there is a real benefit, because tls_write takes a buffer that will be packed into a TLS record. The buffer is not copied nor stored, I'm not sure about the benefits here. Same goes for tls_get_write_buffer which provides access to internal buffer (no copy). I think that maybe it would be trivial to store a list of iovec structures instead of TLSe write buffer, but this will not be backwards compatible. But I also think you would be better using TLSe + kTLS + splice/sendfile instead. Also, I don't recommend using the synchronous SSL_* compatible APIs. Those perform indeed some socket I/O, but only at a basic level. Note that this is an open-source product (public-domain). Feel free to contribute with anything you consider useful by cloning and PR. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AScbLt2SDhMM6GPUOdkT76mCdSkiybLfks5vS270gaJpZM4baAg2> .