From: Johnnynator <Johnnynator@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [ISSUE] [CLOSED] nginx aarch64-musl cannot serve over HTTPS
Date: Mon, 17 May 2021 13:49:15 +0200 [thread overview]
Message-ID: <20210517114915.n-TQuPH7yFcBZe_58aN__26KFArgi9bT5__srge9Zfg@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-30945@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 6628 bytes --]
Closed issue by cyckl on void-packages repository
https://github.com/void-linux/void-packages/issues/30945
Description:
<!-- Don't request update of package. We have a script for that. https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt . However, a quality pull request may help. -->
### System
It's a Raspberry Pi 4B
* xuname:
* `Void 5.4.83_1 aarch64-musl Unknown uptodate rF`
* package:
* `nginx-1.18.0_4`
Custom image built with `rpi4-kernel` and `rpi4-base`
### Expected behavior
After serving a site on SSL, nginx should send correct response to request for HTTPS content
The following example was taken from `curl` output with the following conditions:
* Server is running on Void x86-64
* `Void 5.11.18_1 x86_64 GenuineIntel uptodate rFFF`
* Same config
* Same certificate
* Same nginx version
* `nginx-1.18.0_4`
* Domain name has been censored.
```
~ # curl -vi https://example.com
* Trying 127.0.0.1:443...
* Connected to example.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=example.com
* start date: May 16 21:47:47 2021 GMT
* expire date: Aug 14 21:47:47 2021 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found
< Server: nginx/1.18.0
Server: nginx/1.18.0
< Date: Mon, 17 May 2021 08:04:26 GMT
Date: Mon, 17 May 2021 08:04:26 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 153
Content-Length: 153
< Connection: keep-alive
Connection: keep-alive
< Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains
<
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>
* Connection #0 to host example.com left intact
```
### Actual behavior
nginx will send an empty response on SSL requests, at least on my aarch64-musl install of the package
The following example was taken from `curl` output with the following conditions:
* Server is running on Void aarch64-musl
* `Void 5.4.83_1 aarch64-musl Unknown uptodate rF`
* Same config
* Same certificate
* Same nginx version
* `nginx-1.18.0_4`
* Domain name has been censored.
```
* Connected to example.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/cacert.pem
* CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [4060 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=example.com
* start date: May 16 21:47:47 2021 GMT
* expire date: Aug 14 21:47:47 2021 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x15b00d400)
} [5 bytes data]
> GET / HTTP/2
> Host: example.com
> user-agent: curl/7.76.0
> accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
} [5 bytes data]
* Empty reply from server
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
} [5 bytes data]
* TLSv1.3 (OUT), TLS alert, close notify (256):
} [2 bytes data]
curl: (52) Empty reply from server
```
### Steps to reproduce the behavior
* Configure nginx on any aarch64 / aarch64-musl (not sure yet) Void install
* Enable SSL on a server block
* Access from a browser / `curl` from website
### Extra information
* nginx does not log the error in the `error.log` located in `/var/log/nginx/error.log`
* Configuration is known-good on Raspbian
* Attempted to use stock config shipped with package on Void and enabling SSL to no avail, same issue
* Works on x86-64 with the exact same configuration, certificates, domain, package version
### Ideas
As I've tested the exact same package on different architectures, the only difference between the two is that there is a patch for the nginx package applied for ARM systems. It appears that the patch is in order to adjust certain configuration values on compilation to fit the ARM architecture, which also leads me to believe that it could be related. A good way to test would be with a few different architectures to see if it's only limited to ARM or maybe something platform specific.
It could also be musl specific, as that is another difference between the two systems and that difference has been known to break packages historically.
next prev parent reply other threads:[~2021-05-17 11:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 8:24 [ISSUE] nginx aarch64 cannot serve SSL content cyckl
2021-05-17 10:06 ` nginx aarch64-musl cannot serve over HTTPS Johnnynator
2021-05-17 10:12 ` paper42
2021-05-17 11:14 ` Johnnynator
2021-05-17 11:14 ` Johnnynator
2021-05-17 11:17 ` Johnnynator
2021-05-17 11:31 ` Johnnynator
2021-05-17 11:49 ` Johnnynator [this message]
2021-05-17 15:14 ` cyckl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210517114915.n-TQuPH7yFcBZe_58aN__26KFArgi9bT5__srge9Zfg@z \
--to=johnnynator@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).