Hi
…and a Happy New Year to you all!
After following the DIY instructions I have been running EOS on an RPi for many months without problems. Been a very good experience,…thank you!
Yesterday I upgraded to ver 0.3.3 from 0.2.x
The upgrade went smoothly in the sense that the device came back to life, but I can no longer access the embassy Dashboard from an HTTPS connection, (it works OK with HTTP and Tor).
Using a terminal on the client desktop I can see that the embassy server is not providing a “serverhello” as part of the SSL handshake. It is instead providing TLS Alert code 49 which is an “access denied” code and so the connection is closed.
curl -v https://192.168.1.10:443
- Trying 192.168.1.10:443…
- Connected to 192.168.1.10 (192.168.1.10) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt
- CApath: /etc/ssl/certs
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- TLSv1.3 (IN), TLS alert, access denied (561):
- error:14094419:SSL routines:ssl3_read_bytes:tlsv1 alert access denied
- Closing connection 0
curl: (35) error:14094419:SSL routines:ssl3_read_bytes:tlsv1 alert access denied
My immediate thoughts were a mismatch of supported SSL/TLS protocols negotiated during the handshake, but then I reflected on the fact that there really hasn’t been any negotiation as the server doesn’t send a “serverhello” message,… by using the openssl command line below to try and get more data, I can see that the response lines from the server are reported by the client as “???”, … so does this mean the server is sending back data the client doesn’t understand and it is the client that is reporting “Access Denied”?.
openssl s_client -msg -showcerts -connect 192.168.1.10:443 < /dev/null
CONNECTED(00000003)
>>> ??? [length 0005]
16 03 01 01 16
>>> TLS 1.3, Handshake [length 0116], ClientHello
01 00 01 12 03 03 8c cd ef 4f 7a 07 b2 60 31 03
07 b1 12 9e f3 df a8 9d dc 4f 96 1d 8a 0c 8f 10
7b ba 91 c6 03 04 20 09 75 bc b6 56 9c e2 9a be
ce 18 88 36 e7 de 33 bc 1e b8 eb 32 e1 f1 a8 53
97 a3 e9 77 f8 be 69 00 3e 13 02 13 03 13 01 c0
2c c0 30 00 9f cc a9 cc a8 cc aa c0 2b c0 2f 00
9e c0 24 c0 28 00 6b c0 23 c0 27 00 67 c0 0a c0
14 00 39 c0 09 c0 13 00 33 00 9d 00 9c 00 3d 00
3c 00 35 00 2f 00 ff 01 00 00 8b 00 0b 00 04 03
00 01 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00
19 00 18 00 23 00 00 00 16 00 00 00 17 00 00 00
0d 00 2a 00 28 04 03 05 03 06 03 08 07 08 08 08
09 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06
01 03 03 03 01 03 02 04 02 05 02 06 02 00 2b 00
05 04 03 04 03 03 00 2d 00 02 01 01 00 33 00 26
00 24 00 1d 00 20 82 00 cb 7e b2 68 a3 02 97 9b
81 19 7c db 6a 17 fb 05 8e de df 43 73 9c fb f2
9c 8b 21 df 5c 79
<<< ??? [length 0005]
15 03 03 00 02
<<< TLS 1.3, Alert [length 0002], fatal access_denied
02 31
124369879778624:error:14094419:SSL routines:ssl3_read_bytes:tlsv1 alert access denied:…/ssl/record/rec_layer_s3.c:1543:SSL alert number 49
no peer certificate availableNo client certificate CA names sent
SSL handshake has read 7 bytes and written 283 bytes
Verification: OKNew, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
I then SSH connected to the upgraded server and received a warning that the server was offering a new HOST public key which suggested that something related to the SSL/TLS infrastructure of the server has changed. (My assumption was that in upgrading the server, it would try and retain as much of the legacy configuration as possible and the host identity public key would be something to try and keep if possible).
Rather than push into the embassy server and try to figure out the Docker/nginx/SSLTLS config. I just wanted to post this for the Start9 team to ask the following questions:
Q1: Has there been a significant change to SSL/TLS configuration in ver0.3.3 vs 0.2.x ?
Q2: Is it expected that a new Host key would be offered to an SSH client as a result of the upgrade to 0.3.3?
Q3: Do you have any suggestions of what to check as part of debugging the embassy set up to enable https access again?
Thanks for your support and creating a very useful product.