Android 6.0.1 cannot connect using TLSv1.2 about tlse HOT 13 CLOSED

Hello, I've set up a server with the git version (https://rring.me) and it works (Android 6 + Chrome). I've seen that on lynxlynx.ru it doesn't. The only difference is that I use tls_* APIs. I guess in something related to SSL_* APIs. I'll take a look, but it will be almost impossible to replicate without a minimal program that generates this problem. Can you a provide a minimalistic implementation to test with?

from tlse.

Hey, I think it's related to examples/tlssimpleserver.c, because I used it as a reference when I imported TLSe into my project. The only difference is a fork call just after accept (my server is simple forking one), and establishing my own recv/send wrappers with call to SSL_set_io (they're dummy ones now). Code starting from SSL_new call starts in a client child just after SIGALRM timeout setup. I think you may test it too (as well as I will too, when an affected device owner will be available again).

from tlse.

Ok, this morning I migrated to pure tls_* APIs and disabled SSL_COMPATIBLE_INTERFACE define. Still, my http server won't have much benefit from this probably, but it's internal structure became cleaner 😸
I still get "A" on ssl labs. Can you look at it now? https://lynxlynx.ru/

Apart from that I noticed that tls_close_notify did not worked as expected. It did called after socket close, which was a bug of my server. However now with it I see this message from OpenSSL's s_client on successful connection close or timeout:
4151745224:error:140943E8:SSL routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1293:SSL alert number 0.
Other clients give no warnings, but I tested only with curl and firefox.
Is this normal? Should I open another issue about it?

from tlse.

Ok, still doesn't work. I will take a look today or tomorrow (I will also check tls_close_notify). It is a little strange, because in my webserver which uses the exact source you're using it works perfectly.

from tlse.

The main server runs on a mips bigendian router hardware. Just out of curiosity I also directed affected client on a x86 little endian server, and it worked fine after accepting certificate! (using internal IP address). Maybe there are endianness issues somewhere? Messages from android client are the same length where it stuck and in Wireshark their structure is same (of course they're different at each test time). x86 progresses after HANDSHAKE MESSAGE to => FINISHED, then VERIFY DATA (12): follows, whereas mipsbe server gets stuck at HANDSHAKE MESSAGE. Both consume 21 bytes.

from tlse.

For sure this is the problem. I never tested it on BIG ENDIAN, however it should work. Thanks for the info, now I can solve it.

from tlse.

OK. I think is CHACHA20/POLY1305 related. We have: static unsigned long U8TO32(const unsigned char *p) and static void U32TO8(unsigned char *p, unsigned long v). Can you try disabling TLS_WITH_CHACHA20_POLY1305? If it works, for sure that is the problem.

from tlse.

Sure, I will disable it now, but I have to wait for the guy to arrive soon to test. If you can test it too, wait some minutes.

from tlse.

Ok, now it is disabled...

from tlse.

And it works. Android devices prefer chacha20/poly1305. I guess is a matter of rewriting those two functions. (U83TO32 and U32TO8)

from tlse.

you can have a look at https://github.com/libtom/libtomcrypt/tree/develop/src/stream/chacha as ltc now also contains chacha and we had to adapt that part as well

from tlse.

Cool. Next week-end I will resync tomcrypt and use that implementation of chacha. Thanks!

from tlse.

Affected client now loads the page fine, thank you both for support! I will wait for LTC update.

from tlse.