ChaCha20_Poly1305 patch causes connection reset error?

[as-com]

Relevant server configuration:

ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;

• OpenResty 1.11.2.2 (NGINX 1.11.2)
• OpenSSL 1.0.2j, with openssl__chacha20_poly1305_draft_and_rfc_ossl102j.patch
• Ubuntu 14.04 (Docker)

chrome://net-internals log from a cheap Chromebook:

t=1114 [st=   0] +REQUEST_ALIVE  [dt=2872]
t=1114 [st=   0]    DELEGATE_INFO  [dt=1]
                    --> delegate_info = "NavigationResourceThrottle"
t=1115 [st=   1]    URL_REQUEST_DELEGATE  [dt=0]
t=1115 [st=   1]    URL_REQUEST_START_JOB  [dt=0]
                    --> load_flags = 37121 (MAIN_FRAME | MAYBE_USER_GESTURE | VALIDATE_CACHE | VERIFY_EV_CERT)
                    --> method = "GET"
                    --> priority = "HIGHEST"
                    --> url = "https://andrewsun.com/"
t=1115 [st=   1]   +URL_REQUEST_START_JOB  [dt=2869]
                    --> load_flags = 37121 (MAIN_FRAME | MAYBE_USER_GESTURE | VALIDATE_CACHE | VERIFY_EV_CERT)
                    --> method = "GET"
                    --> priority = "HIGHEST"
                    --> url = "https://andrewsun.com/"
t=1115 [st=   1]      URL_REQUEST_DELEGATE  [dt=0]
t=1115 [st=   1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=1115 [st=   1]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
                      --> net_error = -2 (ERR_FAILED)
t=1115 [st=   1]      HTTP_CACHE_CREATE_ENTRY  [dt=1]
t=1116 [st=   2]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=1116 [st=   2]     +HTTP_STREAM_REQUEST  [dt=919]
t=1116 [st=   2]        HTTP_STREAM_REQUEST_STARTED_JOB
                        --> source_dependency = 15749 (HTTP_STREAM_JOB)
t=2035 [st= 921]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                        --> source_dependency = 15749 (HTTP_STREAM_JOB)
t=2035 [st= 921]     -HTTP_STREAM_REQUEST
t=2035 [st= 921]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t=2035 [st= 921]        HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
                        --> :authority: andrewsun.com
                            :method: GET
                            :path: /
                            :scheme: https
                            accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
                            accept-encoding: gzip, deflate, sdch, br
                            accept-language: en-US,en;q=0.8
                            cache-control: max-age=0
                            upgrade-insecure-requests: 1
                            user-agent: Mozilla/5.0 (X11; CrOS x86_64 8743.85.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.101 Safari/537.36
t=2036 [st= 922]     -HTTP_TRANSACTION_SEND_REQUEST
t=2036 [st= 922]     +HTTP_TRANSACTION_READ_HEADERS  [dt=1948]
t=3984 [st=2870]        HTTP2_STREAM_ERROR
                        --> description = "ABANDONED (stream_id=1): https://andrewsun.com/"
                        --> status = -101
                        --> stream_id = 1
t=3984 [st=2870]     -HTTP_TRANSACTION_READ_HEADERS
                      --> net_error = -101 (ERR_CONNECTION_RESET)
t=3984 [st=2870]   -URL_REQUEST_START_JOB
                    --> net_error = -101 (ERR_CONNECTION_RESET)
t=3985 [st=2871]    URL_REQUEST_DELEGATE  [dt=1]
t=3986 [st=2872] -REQUEST_ALIVE
                  --> net_error = -101 (ERR_CONNECTION_RESET)

Samsung Galaxy S5: https://www.webpagetest.org/result/161130_TS_J29Z/ After removing ChaCha20 from ssl_ciphers: https://www.webpagetest.org/result/161130_Y5_J46Q/ (what it should look like)

This didn't seem to happen before I updated the patch to the latest one. (I'm not sure which one I used previously, though)

This also doesn't seem to happen with CloudFlare sites.

[rraptorr]

Maybe this is the same issue as in #51 Check your server dmesg for any illegal instruction errors

[as-com]

@rraptorr Interesting...unfortunately, the system logs on my testing production server apparently don't go back that far.

My server's CPU is an Intel Xeon X3220. Even though it's pretty old, it still supports ssse3:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 15
model name  : Intel(R) Xeon(R) CPU           X3220  @ 2.40GHz
stepping    : 11
microcode   : 0xb3
cpu MHz     : 2400.000
cache size  : 4096 KB
physical id : 0
siblings    : 4
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 10
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority dtherm
bugs        :
bogomips    : 4801.96
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

...so this probably isn't same issue.

[mmolchan]

@as-com I noticed similar inconsistency in ChaCha implementation when I configured openssl library with "no-asm". Same happened with 32-bit OpenSSL library, ChaCha failed there, so symptoms look like yours. Do you, by any chance, use 32-bit OpenSSL or compiled with "no-asm"? I would also like to investigate this chacha issue, for me it looks like SSE-optimized code works as expected, while generic implementation does not.

[vkrasnov]

@as-com, the code requires SSE4, but it does not actually perform a CPUID check for that, because SSE4 is pretty old now.