This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I've encountered a serious bug in OpenSSL 1.0.1 on Ubuntu 12.04:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 <- dated Oct 3 2012!
The gist of it is that I'm able to connect to some servers but not others. Connecting to google works:
openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
...
Protocol : TLSv1.1
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397
Session-ID-ctx:
Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD
0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.<.
0020 - 01 1e ad b3 13 de 65 d4-e8 ea e4 35 89 83 55 8e ......e....5..U.
0030 - e4 d5 9f 60 58 51 33 9b-83 34 b9 35 3d 46 cb a3 ...`XQ3..4.5=F..
0040 - 35 7b 48 5d 7b 86 5c d5-a1 14 9d 8c 3e 93 eb fb 5{H]{.\.....>...
0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1.
0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6..
0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon
0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$
0090 - 3c f0 ca a5 <...
Start Time: 1354063165
Timeout : 300 (sec)
Verify return code: 0 (ok)
But connecting to facebook doesn't:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC-SHA
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40))
0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB
0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D
0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h......
0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#.......
>>> TLS 1.1 [length 003b]
01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5
2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61
5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00
00 09 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7))
0000 - 15 03 02 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
<<< TLS 1.1 [length 0002]
02 28
SSL_connect:error in unknown state
140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 64 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
The facebook connection either hangs after the client sends its hello buffer and never receives the server hello response, or returns with an error code if I pass in a cipher it recognizes. This happens with both -tls1 and -ssl3. I've tried every parameter to openssl I can think of.
apt-cache showpkg openssl
...
Provides:
1.0.1-4ubuntu5.5 -
1.0.1-4ubuntu5.3 -
1.0.1-4ubuntu3 -
I've also tried every parameter I can think of to curl but with no success, because it uses openssl under the hood.
I'm concerned that Ubuntu can't establish secure connections (an astounding statement, I realize). After two solid days of beating my head against this problem, I'm basically praying at this point that someone knows a workaround. I'm considering a downgrade to OpenSSL 1.0.0 or using libcurl4-dev with gnutls-dev instead. Both solutions leave a rotten taste in my mouth. Thanks in advance for any help you can provide.
P.S. all of this work is so that my server can interface with external https REST APIs. I consider this a fundamental requirement in any webserver today, no excuses.
UPDATE: Here is my output without passing a cipher. It doesn't matter if I pass -CAfile or not either:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2))
0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj
0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.w.f.H..
0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f..
0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8......
0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............
0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................
0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....E.D....
0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A..........
0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................
0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I.......
00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2.........
00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................
00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................
00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#.....
00e0 - 01 01 ..
>>> TLS 1.1 [length 00dd]
01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62
19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8
c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0
21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02
01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34
00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09
00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15
00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f
00 10 00 11 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
Why are you passing -cipher SRP-AES-256-CBC-SHA when connecting to graph.facebook.com? Facebook certainly doesn't support SRP: http://srp.stanford.edu/.
Does it work if you don't pass that?
Also, can you give the IP address that you're getting? With 69.171.229.17, I can reproduce that exact ClientHello (modulo the nonce and with RC4-SHA are the only cipher save the SCSV) and I get a successful handshake.
Lastly, have you tried doing over an SSH tunnel to somewhere else? Sadly, when deploying TLS features in Chrome we have repeatedly found networking hardware that breaks TLS connections. (Although I can't think of a case where -ssl3 wouldn't fix it unless the hardware was actively trying to censor connections.)
Setting the MTU on my Ubuntu box from 1500 to 1496 (due to one of our firewalls being set too low) allows me to receive a response from the server without having to reboot (be sure to call ifconfig first and write down your original MTU which should be 1500):
sudo ifconfig eth0 mtu 1496
I discovered my MTU by pinging with successively larger buffers (add 28 bytes for UDP header):
Fails for 1472 + 28 = 1500:
ping -s 1472 facebook.com
PING facebook.com (66.220.158.16) 1472(1500) bytes of data.
...
Works for 1468 + 28 = 1496:
ping -s 1468 facebook.com
PING facebook.com (69.171.229.16) 1468(1496) bytes of data.
1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms
...
With 1496 I'm now able to curl to facebook.com:
curl -v https://facebook.com
* About to connect() to facebook.com port 443 (#0)
* Trying 66.220.152.16... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com
* start date: 2012-06-21 00:00:00 GMT
* expire date: 2013-12-31 23:59:59 GMT
* subjectAltName: facebook.com matched
* issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: facebook.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.facebook.com/
< Content-Type: text/html; charset=utf-8
< X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0=
< Date: Wed, 28 Nov 2012 19:52:25 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host facebook.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
I personally think that MTU should have absolutely nothing to do with what the user sees at the stream level with TCP so I hope the OpenSSL folks fix this. I also wish that someone would invent an automagic bug submitter for bugs that are profoundly widespread and time-sucking.
Related
I am trying to secure the Akka Management port of a Scala microservice with TLS by starting Akka Management programatically on port 8558 via AkkaManagement:withHttpsConnectionContext().
When the Scala service is run, it reads from the configuration and starts Akka Management fine, but does not appear to be operating with TLS encryption enabled.
~$ telnet localhost 8558
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /cluster/members HTTP/1.0
Host: 127.0.0.1
HTTP/1.1 200 OK
Server: akka-http/10.4.0
Date: Fri, 27 Jan 2023 20:26:00 GMT
Connection: close
Content-Type: application/json
Content-Length: 439
From what I can tell, Akka Management is serving HTTP from what should be the HTTPS port, and not encrypting the response.
:~$ openssl s_client -connect localhost:8558 -state -debug
CONNECTED(00000003)
SSL_connect:before SSL initialization
write to 0x56097b12c740 [0x56097b13ee80] (283 bytes => 283 (0x11B))
0000 - 16 03 01 01 16 01 00 01-12 03 03 05 27 1c 50 1b ............'.P.
0010 - e6 b6 23 5a e5 da d5 48-29 33 51 08 13 fb b6 aa ..#Z...H)3Q.....
0020 - 23 f4 2e 44 93 75 95 97-59 9a 1c 20 99 b0 36 06 #..D.u..Y.. ..6.
0030 - 1f 3d 79 d0 d8 e8 36 7e-41 5e 2e ff 70 f7 ce a5 .=y...6~A^..p...
0040 - 0a 5a 56 e4 a9 fc 15 09-d0 3c a7 9b 00 3e 13 02 .ZV......<...>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 8b ...=.<.5./......
0090 - 00 0b 00 04 03 00 01 02-00 0a 00 0c 00 0a 00 1d ................
00a0 - 00 17 00 1e 00 19 00 18-00 23 00 00 00 16 00 00 .........#......
00b0 - 00 17 00 00 00 0d 00 2a-00 28 04 03 05 03 06 03 .......*.(......
00c0 - 08 07 08 08 08 09 08 0a-08 0b 08 04 08 05 08 06 ................
00d0 - 04 01 05 01 06 01 03 03-03 01 03 02 04 02 05 02 ................
00e0 - 06 02 00 2b 00 05 04 03-04 03 03 00 2d 00 02 01 ...+........-...
00f0 - 01 00 33 00 26 00 24 00-1d 00 20 4e 63 c8 62 95 ..3.&.$... Nc.b.
0100 - f3 8e a4 b2 04 44 1a 83-6e 53 99 4b ef d0 f7 51 .....D..nS.K...Q
0110 - eb 95 b5 8c 1d 3c f7 f7-fa c1 1b .....<.....
SSL_connect:SSLv3/TLS write client hello
read from 0x56097b12c740 [0x56097b135c63] (5 bytes => 5 (0x5))
0000 - 48 54 54 50 2f HTTP/
SSL_connect:error in error
139911147234624:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 283 bytes
Verification: OK
---
New, (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)
---
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 189 (0xBD))
0000 - 31 2e 31 20 34 30 30 20-42 61 64 20 52 65 71 75 1.1 400 Bad Requ
0010 - 65 73 74 0d 0a 53 65 72-76 65 72 3a 20 61 6b 6b est..Server: akk
0020 - 61 2d 68 74 74 70 2f 31-30 2e 34 2e 30 0d 0a 44 a-http/10.4.0..D
0030 - 61 74 65 3a 20 46 72 69-2c 20 32 37 20 4a 61 6e ate: Fri, 27 Jan
0040 - 20 32 30 32 33 20 32 30-3a 33 36 3a 30 32 20 47 2023 20:36:02 G
0050 - 4d 54 0d 0a 43 6f 6e 6e-65 63 74 69 6f 6e 3a 20 MT..Connection:
0060 - 63 6c 6f 73 65 0d 0a 43-6f 6e 74 65 6e 74 2d 54 close..Content-T
0070 - 79 70 65 3a 20 74 65 78-74 2f 70 6c 61 69 6e 3b ype: text/plain;
0080 - 20 63 68 61 72 73 65 74-3d 55 54 46 2d 38 0d 0a charset=UTF-8..
0090 - 43 6f 6e 74 65 6e 74 2d-4c 65 6e 67 74 68 3a 20 Content-Length:
00a0 - 32 33 0d 0a 0d 0a 55 6e-73 75 70 70 6f 72 74 65 23....Unsupporte
00b0 - 64 20 48 54 54 50 20 6d-65 74 68 6f 64 d HTTP method
read from 0x56097b12c740 [0x56097b123f00] (8192 bytes => 0 (0x0))
It also looks like attempting to access Akka Management with TLS is also failing completely.
I'm seeing the following log message on the microservice when using the openssl command:
[WARN] [akka.actor.ActorSystemImpl] [] [inbound-transaction-akka.actor.default-dispatcher-65] [] [] [] [] - Illegal request, responding with status '400 Bad Request': Unsupported HTTP method: The HTTP method started with 0x16 rather than any known HTTP method from 192.168.96.1:39184. Perhaps this was an HTTPS request sent to an HTTP endpoint?
I tried starting Akka Management programatically with TLS encryption, and got unencrypted HTTP instead.
Here is the code used to setup HTTPS and start Akka Management:
def getHttpsConnectionContext(config: HttpsConfig): SSLContext = {
val keystore: KeyStore = KeyStore.getInstance("PKCS12")
val keystoreFile: InputStream =
getClass.getClassLoader.getResourceAsStream(config.keystoreFile)
val keystorePassword = config.keystorePassword.toCharArray
keystore.load(keystoreFile, keystorePassword)
val keyManagerFactory: KeyManagerFactory =
KeyManagerFactory.getInstance("SunX509")
keyManagerFactory.init(keystore, keystorePassword)
val trustManagerFactory: TrustManagerFactory =
TrustManagerFactory.getInstance("SunX509")
trustManagerFactory.init(keystore)
val sslContext: SSLContext = SSLContext.getInstance("TLS")
sslContext.init(
keyManagerFactory.getKeyManagers,
trustManagerFactory.getTrustManagers,
new SecureRandom
)
sslContext
}
val httpsConfig: HttpsConfig =
HttpsConfig(
actorSystem.settings.config,
"akka.moo.https"
) match {
case Some(value) => value
case None => throw new ConfigurationException("Bad HTTPS config")
}
val sslContext: SSLContext =
HttpsContext.getHttpsConnectionContext(httpsConfig)
val httpsServer: HttpsConnectionContext =
ConnectionContext.httpsServer(sslContext)
val management = AkkaManagement(actorSystem)
management.start(_.withHttpsConnectionContext(httpsServer))
I'm not sure what the problem here is.
Thank you ahead of time for your help.
I am trying to use mitmproxy to look at the traffic from my win32 schannel tls client. But when I try to use mitmproxy the following messages throw an "Bad HTTP request line" error with a leading 0 in the binary dump that does not exsist in the data that my client sends (I have checked with a little python server).
"CONNECT www.example.com:443 HTTP/1.0\r\n\r\n"
"HTTP/1.0 200 Connection established\r\n\r\n"
Send Tls Client Hello:
16 03 03 00 AC 01 00 00 A8 03 03 5F 80 1A 2D F6 2A 59 DE 18
69 F0 BB 3C 2D 2B 11 90 F8 8C A7 F9 D7 96 CD DC 32 88 02 22
11 90 6A 00 00 2A C0 2C C0 2B C0 30 C0 2F 00 9F 00 9E C0 24
C0 23 C0 28 C0 27 C0 0A C0 09 C0 14 C0 13 00 9D 00 9C 00 3D
00 3C 00 35 00 2F 00 0A 01 00 00 55 00 00 00 14 00 12 00 00
0F 77 77 77 2E 65 78 61 6D 70 6C 65 2E 63 6F 6D 00 0A 00 08
00 06 00 1D 00 17 00 18 00 0B 00 02 01 00 00 0D 00 1A 00 18
08 04 08 05 08 06 04 01 05 01 02 01 04 03 05 03 02 03 02 02
06 01 06 03 00 23 00 00 00 17 00 00 FF 01 00 01 00
Bad HTTP request line: b"\x00\x16\x03\x03\x00\xac\x01\x00\x00\xa8\x03\x03_\x80\x17\xbd\x1f\xf3\x8fO\xddy\xfb\xaaR\x1c\xeb\xe0sdD\xb7}|\xeb\xbes\xdf$3\xb6\xd9\ry\x00\x00*\xc0,\xc0+\xc00\xc0/\x00\x9f\x00\x9e\xc0$\xc0#\xc0(\xc0'\xc0"
Now my question: Is this just a lack of understanding in how proxys and tls work or an error from mitmproxy?
I'm using Akka Streams to create a TCP server using akka.stream.scaladsl.TLS with client certificate authentication. I'm working on creating an echo server as a first proof of concept.
In the meantime, I'm new to Scala/Akka/Akka Streams and so I created a similar server and TCP client in Python to provide tooling in testing my work in Scala. The Python server/client are functional using client cert authentication. When connecting to the server, the client takes the following steps:
Creates and configures an SSLContext
Creates a socket using socket.create_connection()
Wraps the socket with the SSLContext using SSLContext.wrap_socket(). This creates the peer connection
Once connected, prints the server certificate
Infinite loop asking for input and sending each input to the server
I believe I have the server completed using Akka Streams and akka.stream.scaladsl.TLS, but when I attempt to connect using my Python client the client never gets past connecting to the peer using context.wrap_socket(sock, server_hostname=host). The server successfully binds the TCP connection and creates the corresponding IncomingConnection object. The client/server also never timeout (the client just sits awaiting the handshake?).
My biggest problem is that I see no information from my TLS BidiFlow, akka.stream.scaladsl.TLS. I have no idea what step in the handshake I'm stuck at, which makes troubleshooting very difficult.
Is there any way to output some information throughout the TLS handshake process? It seems as though all of the functionality is encapsulated and I don't know if there's any way to troubleshoot.
Otherwise, I'm attempting to troubleshoot with openssl and get the following:
bash$ openssl s_client -connect myserver.com:443 -state -debug
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x7fd914100080 [0x7fd915001000] (318 bytes => 318 (0x13E))
0000 - 16 03 01 01 39 01 00 01-35 03 03 e3 ff 5d fb 26 ....9...5....].&
0010 - 15 e3 32 89 37 e2 cb 95-f5 00 bd df 13 3d ae a6 ..2.7........=..
0020 - d7 37 db 4e 80 19 63 ad-d6 6c f1 00 00 98 cc 14 .7.N..c..l......
0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a .....0.,.(.$....
0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4 .....k.j.9.8....
0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26 .........2...*.&
0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f .......=.5...../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g
0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31 .#.3.2.....E.D.1
0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./
00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04 ...A............
00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15 ................
00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00 .........t......
00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c .....:.8........
00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16 ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05 ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11 ................
0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03 .#.....&.$......
0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee ................
0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03 ..............
SSL_connect:unknown state
At which point openssl just hangs.
The Akka TLS support uses the built in Java TLS support behind the scenes, so to get debug output for TLS you'll have to enable debugging for that. It can be done through passing a system property to the JVM when starting it like so -Djavax.net.debug=all
Ultimately I found that the ssl-config logging is very sparse and wasn't helpful to resolving my issue. It does provide some debugging information but not much. Much better for debugging the TLS handshake is to use the -Djavax.net.debug=all flag when running the JVM. However, even this provides mixed results. For example, the resulting error I received is that the server couldn't find a matching cipher suite. Eventually I resolved my issue by realizing that when creating the input streams for my keystore/truststore I was specifying my path incorrectly.
Note for anyone coming across this: if you specify your keystore and truststore incorrectly the resulting input streams will be null and SSLContext.init will happily use these and provide an error that is unrelated to the keystore/truststore! This was very difficult to troubleshoot due to the incorrect error handling in SSLContext.
I have a digital signature (RSA - PKCS#1). After decrypting it with the RSA public key I get the following 128 bytes
00 01 ff ff ff .. ff 00 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
PKCS#1 padding removed, 51 bytes left:
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 77 51 1b f4 d7 17 d7 ad 8c 2d e5 89 2a ca e0 6d a3 c0 7d 13 4d d7 b8 01 14 87 03 00 69 e4 9b b3
I would like two things about this:
Is it possible to determine the hash function used? Encoded algorithm ID should be prepended to the actual body of the digest, is it possible to tell what algorithm it is from the raw bytes?
Where does the actual digest start (how long the head / digest is)?
This appears to be EMSA-PKCS1-v1_5 as described in RFC 3447, which means that after removing the header and padding, you have a DER encoding of an AlgorithmIdentifier followed by the hash value itself.
From the RFC:
For the six hash functions mentioned in Appendix B.1, the DER
encoding T of the DigestInfo value is equal to the following:
[...]
SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H.
So in your example, the hash value is the SHA-256 hash starting 77511bf4d7....
Upgraded Webbit to 0.4.6 to use the new SSL support but immediately realized that all wss:// handshakes are failing silently and I don't have any errors to show for it. Chrome only reports a "success" for a response without a HTTP code or any other headers. I check server logs and it doesn't even register an "open" event.
The catch here is that any ws:// connection works great. So what could be possible problems and how can I get an error out of it? Could it be something wrong with the java keystore and SSL handshake?
Edit
I was able to find an openSSL command for a test handshake. Here's the output:
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
Edit 2
I realized I could debug this further
CONNECTED(0000016C)
SSL_connect:before/connect initialization
write to 0x1f57750 [0x1f6a730] (210 bytes => 210 (0xD2))
0000 - 16 03 01 00 cd 01 00 00-c9 03 01 4f 6b 8d 68 63 ...........Ok.hc
0010 - 99 06 08 30 93 2a 42 88-f8 f1 c4 c5 dc 89 71 0b ...0.*B.......q.
0020 - b6 04 42 4e 11 79 b4 76-6c f7 66 00 00 5c c0 14 ..BN.y.vl.f..\..
0030 - c0 0a 00 39 00 38 00 88-00 87 c0 0f c0 05 00 35 ...9.8.........5
0040 - 00 84 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................
0050 - c0 13 c0 09 00 33 00 32-00 9a 00 99 00 45 00 44 .....3.2.....E.D
0060 - c0 0e c0 04 00 2f 00 96-00 41 00 07 c0 11 c0 07 ...../...A......
0070 - c0 0c c0 02 00 05 00 04-00 15 00 12 00 09 00 14 ................
0080 - 00 11 00 08 00 06 00 03-00 ff 01 00 00 44 00 0b .............D..
0090 - 00 04 03 00 01 02 00 0a-00 34 00 32 00 01 00 02 .........4.2....
00a0 - 00 03 00 04 00 05 00 06-00 07 00 08 00 09 00 0a ................
00b0 - 00 0b 00 0c 00 0d 00 0e-00 0f 00 10 00 11 00 12 ................
00c0 - 00 13 00 14 00 15 00 16-00 17 00 18 00 19 00 23 ...............#
00d2 - <SPACES/NULS>
SSL_connect:SSLv2/v3 write client hello A
read from 0x1f57750 [0x1f6fc90] (7 bytes => 0 (0x0))
12488:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 210 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Edit 3
Ok I've nailed the problem to Webbit initialization, but it doesn't throw any errors so I could use some input to getting getResourceAsStream functioning properly. Here's how the server is initialized:
def startWebSocketServer(webSocketHandler:PartialFunction[WebSocketEvent, Unit]) {
val webServer = WebServers.createWebServer(port)
try {
webServer.setupSsl(getClass.getResourceAsStream("/keystore"), "webbit")
webServer.add("/", new WebSocketEventAdapter(webSocketHandler))
webServer.start
} catch {
case e => e.printStackTrace()
}
}
Unfortunately setupSsl won't output any information, and I've tried both what I thought would be the path and inserting a fake path. In either case, I can't get an error. How on earth would I properly locate the path? Thanks!
The OMFG Answer
In a hysterical twist of fate, I found the problem. This particular issue took up 48 hours of my time, but the cause was not even code related and a funny miscommunication.
So as it turns out, another developer had copied our websocket code into a new file he was working on for development. All this time we were trying to debug code in a file that wasn't even executing at run-time. So upon further investigation we scrolled to the bottom of a very long and different file, and found the webbit init code and excuted it perfectly.
Moral of the story: don't commit an incomplete file to the master branch and point everyone there for debugging ;)