Does Bluetooth encrypt data? [closed]

Does Bluetooth encrypt data? [closed] - encryption

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Intro: I'm coming to this problem without full familiarity with the Bluetooth stack and protocols, so this may require several rounds of editing as errors in my assumptions are revealed.
I'm attempting to connect to a Bluetooth device, a Scosche myTREK Pulse Monitor. I was able to connect to the device using the 'official' app for Android, and I captured the Bluetooth packet output using hcidump. I can read and understand the connection process up through the link key exchange; however, the device then sends an HCI Encrypt Change event, after which most (but not all) packets are labeled as ACL packets, and are difficult to interpret.
The basic question is: Does Bluetooth encrypt data, and is there a way to decrypt it securely? Is this related to the shift to ACL packets?
Here is a sample of the packet output provided by hcidump for a given connection, starting at the passing of the Link Key. ( > refers to the monitor sending data )
> HCI Event: Link Key Request (0x17) plen 6
0000: ** ** ** ** ** ** ??????
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
0000: ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ???????????????
0010: ** ** ** ** ** ** ??????
> HCI Event: Command Complete (0x0e) plen 10
0000: 01 0b 04 00 ** ** ** ** ** ** ....??????
> HCI Event: Encrypt Change (0x08) plen 4
0000: 00 0c 00 01 ....
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
< ACL data: handle 12 flags 0x00 dlen 16
0000: 0c 00 01 00 03 02 08 00 40 00 40 00 01 00 00 00 ........#.#.....
< ACL data: handle 12 flags 0x00 dlen 10
0000: 06 00 01 00 0a 01 02 00 02 00 ..........
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 0c 00 02 00 .....
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 12 flags 0x00 dlen 16
0000: 0c 00 01 00 03 02 08 00 40 00 40 00 00 00 00 00 ........#.#.....
< ACL data: handle 12 flags 0x00 dlen 12
0000: 08 00 01 00 04 02 04 00 40 00 00 00 ........#...
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 0c 00 02 00 .....
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
< ACL data: handle 12 flags 0x00 dlen 18
0000: 0e 00 01 00 05 03 0a 00 40 00 00 00 00 00 01 02 ........#.......
0010: 30 00 0.
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> ACL data: handle 12 flags 0x02 dlen 36
L2CAP(d): cid 0x0040 len 32 [psm 0]
0000: 06 00 01 00 1b 35 11 1c 00 00 00 00 de ca fa de .....5......??·?
0010: de ca de af de ca ca fe 00 26 35 03 09 00 04 00 ???»????.&5.....
< ACL data: handle 12 flags 0x00 dlen 33
0000: 1d 00 40 00 07 00 01 00 18 00 15 35 13 35 11 09 ..#........5.5..
0010: 00 04 35 0c 35 03 19 01 00 35 05 19 00 03 08 12 ..5.5....5......
0020: 00 .
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 0c 00 02 00 .....
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 12 flags 0x00 dlen 12
0000: 08 00 01 00 07 04 04 00 40 00 40 00 ........#.#.
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0041
< ACL data: handle 12 flags 0x00 dlen 16
0000: 0c 00 01 00 03 05 08 00 40 00 41 00 00 00 00 00 ........#.A.....
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 0c 00 02 00 .....
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 895
< ACL data: handle 12 flags 0x00 dlen 18
0000: 0e 00 01 00 05 06 0a 00 41 00 00 00 00 00 01 02 ........A.......
0010: 7f 03 ..
< ACL data: handle 12 flags 0x00 dlen 16
0000: 0c 00 01 00 04 03 08 00 41 00 00 00 01 02 f5 03 ........A.....?.
> HCI Event: Number of Completed Packets (0x13) plen 5
0000: 01 0c 00 02 00 .....
> ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 1013
At this point, the payloads delivered by the device vary drastically between runs, much less within a single run. I've placed the remainder of the log in a pastebin for brevity: Link

Yes, bluetooth encrypts data over the air. And yes, this applies to ACL data. But the data you are seeing over the HCI interface is already decrypted. Your problem is that you don't know how to interpret the ACL data stream. There are a couple levels of protocol on top of ACL data. Unless your device documents their protocol, you may be out of luck. It's most likely that they are running SPP (serial port profile) or RFCOMM to talk to the android app. So you have the following nested protocol layers to decode SPP -> RFCOMM -> L2CAP -> ACL data.
It is also possible that your device/app do additional application level encryption on top of SPP. In that case, you're out of luck.

Related

Azure Sphere UART no reading 0x00 from serial device

I am reading data from a device through the serial port. I am using a Max3232 converter RS232 to TTL. The odd thing here is that when I use the read function to retrieve the data received by the UART, it eliminates all the 0x00 bytes.
I have used the same converter to read data from the same device using both Arduino Mega and Raspberry PI 3 B+. With both I can read the 0x00 values.
Reading with Arduino and Raspberry
f7 00 00 15 10 22 00 02 28 02 00 00
f2 16 06 00 00 00 00 67 63 02 45 43
Same readings with Azure Sphere
f7 15 10 22 02 28 02
f2 16 06 67 63 02 45 43
Am I missing some setting?

Can anyone advise how I can get the TCP / IP packet checksums verified?

I have a packet that I have manually created for a SYN/ACK but I get no reply from the server.
This is all wireless/GSM stuff so I cannot use a sniffer.
I have calculated the TCP and the IP header checksums manually a few times and they seem correct but I really need a 3rd party method to be sure.
I had several endian issues but I think I have it right now. But who knows...
I only found an online parser but it does not test/verify the checksums.
Does anyone have an easy idea for me?
Just in case someone has suitable access to a test method, and feels like pasting it in for me, here is the packet:
45 10 00 3C 00 02 00 00 64 06 E8 1F 0A AA 61 43 51 8A B1 13
01 BB 01 BB 00 00 00 0A 00 00 00 00 50 02 00 00 3D D8 00 00
Regards
berntd

I've creating a pcap from your hex data using Net::PcapWriter:
use strict;
use warnings;
use Net::PcapWriter;
my $w = Net::PcapWriter->new('test.pcap');
my $ip = pack('H*','4510003C000200006406E81F0AAA6143518AB11301BB01BB0000000A00000000500200003DD80000');
$w->packet($w->layer2prefix('1.1.1.1').$ip);
Loading it into Wireshark shows both the IP checksum and the TCP checksum as correct, so it is probably not a problem of the checksum calculation.
But tcpdump says that the length is wrong:
IP truncated-ip - 20 bytes missing! 10.170.97.67.443 > 81.138.177.19.443: Flags [S], seq 10:30, win 0, length 20
This is because you've set the total length in the IP header to 60 bytes (00 3C) but the IP header + TCP header is only 40 bytes in total and your packet does not have any payload, i.e. the total length should be 40 and not 60 bytes.

Here is what I came up with to do it the manual way:
Put packet into a text file like so:
45 10 00 3C 00 02 00 00 64 06 E8 1F 0A AA 61 43 51 8A B1 13
01 BB 01 BB 00 00 00 0A 00 00 00 00 50 02 00 00 3D D8 00 00
add addressing offsets and group into 16 byte lines as in a hex dump:
000000 45 10 00 3C 00 02 00 00 64 06 E8 1F 0A AA 61 43
000010 51 8A B1 13 01 BB 01 BB 00 00 00 0A 00 00 00 00
000020 50 02 00 00 3D D8 00 00
Save it (source).
Now run ext2pcap.exe -e 0x800 source dest
The dest file can now be imported as a PCAP file into wireshark for decoding.
Multiple packets can be converted byt starting the address offset for each new packet at 000000 again in the source file.
text2pcap.exe seems to come with wireshark.
Tedious but works.
Cheers

SSLPeerUnverifiedException exception

I am trying to trigger HTTP Get request using the code below:
httpBuilder = new HTTPBuilder(url)
httpBuilder.setHeaders(['Authorization':'Basic MyKey'])
httpBuilder.request( GET, JSON ) {
response.success = { resp, reader ->
.......
I know the key is correct but I keep getting "peer not authenticated" from Assembly payment for the url: https://test.api.promisepay.com/users
I check the exception class and its SSLPeerUnverifiedException. Seems like something to do with the TLS protocol.
Update:
I ran the following 2 commands:
echo -n | openssl s_client -connect test.api.promisepay.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/test.api.promisepay.com.cert
Certificate was download and stored in /tmp/test.api.promisepay.com.cert
sudo keytool -importcert -alias "assembly" -file /tmp/test.api.promisepay.com.cert -keystore /opt/java/jre/lib/security/cacerts -storepass changeit
Certificate was successfully imported into keystore but its still throwing error SSLPeerUnverifiedException exception.
Update 2:
trustStore is: /opt/jdk1.7.0_80/jre/lib/security/cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
Algorithm: RSA; Serial number: 0x4eb200670c035d4f
Valid from Wed Oct 25 14:06:00 IST 2006 until Sat Oct 25 14:06:00 IST 2036
adding as trusted cert:
Subject: EMAILADDRESS=info#valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Issuer: EMAILADDRESS=info#valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Algorithm: RSA; Serial number: 0x1
Valid from Sat Jun 26 03:53:48 IST 1999 until Wed Jun 26 03:53:48 IST 2019
adding as trusted cert:
Subject: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
Algorithm: RSA; Serial number: 0x344ed55720d5edec49f42fce37db2b6d
Valid from Fri Nov 17 05:30:00 IST 2006 until Thu Jul 17 05:29:59 IST 2036
adding as trusted cert:
Subject: CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US
Issuer: CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US
Algorithm: RSA; Serial number: 0x456b5054
Valid from Tue Nov 28 01:53:42 IST 2006 until Sat Nov 28 02:23:42 IST 2026
adding as trusted cert:
Subject: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
Algorithm: RSA; Serial number: 0x1121bc276c5547af584eefd4ced629b2a285
Valid from Tue May 26 05:30:00 IST 2009 until Tue May 26 05:30:00 IST 2020
adding as trusted cert:
Subject: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
Issuer: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
Algorithm: RSA; Serial number: 0xc9cdd3e9d57d23ce
Valid from Fri Aug 01 18:01:40 IST 2008 until Sat Jul 31 18:01:40 IST 2038
/// Lots of adding as trusted cert messages...........
trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
http-bio-8080-exec-2, setSoTimeout(0) called
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:
GMT: 1513260023
bytes = {
59,
22,
52,
225,
123,
49,
3,
40,
88,
64,
182,
97,
150,
68,
98,
52,
74,
82,
175,
184,
181,
239,
34,
60,
214,
113,
43,
80 }
Session ID:
{}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: {
0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
***
[write] MD5 and SHA1 hashes: len = 149
0000: 01 00 00 91 03 01 5A 33 84 F7 3B 16 34 E1 7B 31 ......Z3..;.4..1
0010: 03 28 58 40 B6 61 96 44 62 34 4A 52 AF B8 B5 EF .(X#.a.Db4JR....
0020: 22 3C D6 71 2B 50 00 00 2A C0 09 C0 13 00 2F C0 "<.q+P..*...../.
0030: 04 C0 0E 00 33 00 32 C0 08 C0 12 00 0A C0 03 C0 ....3.2.........
0040: 0D 00 16 00 13 C0 07 C0 11 00 05 C0 02 C0 0C 00 ................
0050: 04 00 FF 01 00 00 3E 00 0A 00 34 00 32 00 17 00 ......>...4.2...
0060: 01 00 03 00 13 00 15 00 06 00 07 00 09 00 0A 00 ................
0070: 18 00 0B 00 0C 00 19 00 0D 00 0E 00 0F 00 10 00 ................
0080: 11 00 02 00 12 00 04 00 05 00 14 00 08 00 16 00 ................
0090: 0B 00 02 01 00 .....
http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 149
[Raw write]: length = 154
0000: 16 03 01 00 95 01 00 00 91 03 01 5A 33 84 F7 3B ...........Z3..;
0010: 16 34 E1 7B 31 03 28 58 40 B6 61 96 44 62 34 4A .4..1.(X#.a.Db4J
0020: 52 AF B8 B5 EF 22 3C D6 71 2B 50 00 00 2A C0 09 R...."<.q+P..*..
0030: C0 13 00 2F C0 04 C0 0E 00 33 00 32 C0 08 C0 12 .../.....3.2....
0040: 00 0A C0 03 C0 0D 00 16 00 13 C0 07 C0 11 00 05 ................
0050: C0 02 C0 0C 00 04 00 FF 01 00 00 3E 00 0A 00 34 ...........>...4
0060: 00 32 00 17 00 01 00 03 00 13 00 15 00 06 00 07 .2..............
0070: 00 09 00 0A 00 18 00 0B 00 0C 00 19 00 0D 00 0E ................
0080: 00 0F 00 10 00 11 00 02 00 12 00 04 00 05 00 14 ................
0090: 00 08 00 16 00 0B 00 02 01 00 ..........
http-bio-8080-exec-2, received EOFException: error
http-bio-8080-exec-2, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
http-bio-8080-exec-2
, SEND TLSv1 ALERT:
fatal,
description = handshake_failure
http-bio-8080-exec-2, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 28 ......(
http-bio-8080-exec-2, called closeSocket()
http-bio-8080-exec-2, IOException in getSession(): javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
http-bio-8080-exec-2, called close()
http-bio-8080-exec-2, called closeInternal(true)
http-bio-8080-exec-2, called close()
http-bio-8080-exec-2, called closeInternal(true)
Exception javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Finalizer, called close()
Finalizer, called closeInternal(true)

The root certificate of your certificate chain was added to the default trust store with Java 8u51.
You have to do one of the following tasks:
use a new Java version, at least 8u51
allow untrusted certificates in your client
add that specific certificate as trusted certificate
add that root certificate as trusted root certificate

NFC communication - Mifare DESFire EV1 - AES - Init Vector

I'm using a HID Omnikey 5321 reader to communicate with a Mifare DESFire EV1 tag. I want to write 16 bytes in a standard data file. I'm using the WinSCard DLL (C++) to wrap Native DESFire command in ISO 7816 APDU message structure.
I manage to write data in existing file:
File Nb : 00
Offset : 00 00 00
Length : 10 00 00 (LSB first)
Data (16 bytes) : 23 00 00 00 00 00 00 08 12 34 56 78 00 00 00 00
I calculate the CRC from the Native command :
Native command : 3D (File Nb) (Offset) (Length) (Data)
CRC = 30 D2 07 00
Then I encipher with the session key and an IV set to 00 :
32 bytes data to encipher : (Data) (CRC) 00 00 00 00 00 00 00 00 00 00 00 00
APDU sended :
90 3D 00 00 27 00 00 00 00 10 00 00 (32 bytes enciphered data) 00
But I have problem when I try to write in file I create before.
After AES authentication with Application Master Key, I calculate the two subkey (K1 and K2). I set IV to 0x00...00. Then I create two file :
File 0
CMAC calculation :
(CD 00 03 00 21 30 00 00 80 00...00) XOR (K2)
encryption with session key and IV
copy of encryption result into IV
APDU sended : 90 CD 00 00 07 00 03 00 21 30 00 00 00
Creation file 0 OK
File 1
CMAC calculation :
(CD 01 03 00 11 F0 05 00 80 00...00) XOR (K2)
encryption with session key and IV
copy of encryption result into IV
APDU sended : 90 CD 00 00 07 01 03 00 11 F0 05 00 00
Creation file 1 OK
Then I write data in file 0 in using IV for encryption. I get "1E" error.
I manage to read data in an already existing file :
CMAC calculation
(BD 00 00 00 00 10 00 00 80 00...00) XOR (K2)
encryption with session key and IV = 0x00...00
copy of encryption result into IV
I use IV to decrypt the data I receive and I get good bytes values. So I think the subkey K2 is good.
I don't know where the problem in my write data command. It may be the IV but I don't know why.

SSL Handshake fails after clienthello

EDIT: I'll leave this as a good example of debugging SSL.
Final analysis: We had a networking issue in which one of our routers was misconfigured for a totally different application causing that router to be running borderline on CPU usage. The first few handshakes didn't pin it... then a subsequent one did and the connection was dropped as the router became overloaded. This presented as an SSL problem when it was really something else entirely.
Take-away: When SSL drops completely in mid connection make sure to check load level of routers in your control as well.
I've been at this for a while so hopefully I can provide an accurate picture.
We have SVN and Git repositories at a third party provider. We noticed that each would hang intermittently with no error given to the screen. In SVN's case the process had to be kill -9ed in Git a ctrl-C would suffice.
Looking into I found that the SSL handshake negotiation was failing. In SVN we would get to the handshake part and ... nothing.
Now, I know we use these repos elsewhere without known issues, so that is the first rabbithole I go down.
This only happens on one datacenter. Not in our whoel network. These repos are fine everywhere, else, but at this one datacenter about 1 in 3ish requests hangs on the SSL handshake.
These same machines can access SSL handshakes without issue everywhere else except this third party provider.
So, I delved into the SSL handshake, and finally landed at:
openssl s_client -msg -debug -state -connect DOMAIN.DOM:443 which stops here:
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x20b94e0 [0x20b9560] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 88 0a 00 73 97 ....8...4.....s.
0010 - 12 69 c9 00 65 29 10 f6-57 00 57 44 e8 0e 3f cf .i..e)..W.WD..?.
0020 - af a0 f9 80 e2 20 98 f0-d2 79 8c 00 00 9e c0 30 ..... ...y.....0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$.....".!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.....2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*.&.......=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d ................
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ...../.+.'.#....
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .........g.#.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .....E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 c0 11 .......<./...A..
00b0 - c0 07 c0 0c c0 02 00 05-00 04 00 15 00 12 00 09 ................
00c0 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 6d ...............m
00d0 - 00 0b 00 04 03 00 01 02-00 0a 00 34 00 32 00 0e ...........4.2..
00e0 - 00 0d 00 19 00 0b 00 0c-00 18 00 09 00 0a 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 20-00 1e 06 01 06 02 06 03 .#..... ........
0120 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02 ................
0130 - 03 03 02 01 02 02 02 03-00 0f 00 01 01 .............
>>> TLS 1.2 Handshake [length 0138], ClientHello
01 00 01 34 03 03 88 0a 00 73 97 12 69 c9 00 65
29 10 f6 57 00 57 44 e8 0e 3f cf af a0 f9 80 e2
20 98 f0 d2 79 8c 00 00 9e c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a c0 22 c0 21 00 a3 00 9f 00 6b 00
6a 00 39 00 38 00 88 00 87 c0 32 c0 2e c0 2a c0
26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 12 c0
08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0
2f c0 2b c0 27 c0 23 c0 13 c0 09 c0 1f c0 1e 00
a2 00 9e 00 67 00 40 00 33 00 32 00 9a 00 99 00
45 00 44 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00
9c 00 3c 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 01 00 00 6d 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
0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
02 02 03 00 0f 00 01 01
SSL_connect:unknown state
And it hangs there. On successful connections the next lines to that debug output should be
read from 0x1735590 [0x173ab70] (7 bytes => 7 (0x7))
0000 - 16 03 03 00 42 02 ....B.
0007 - <SPACES/NULS>
read from 0x1735590 [0x173ab7a] (64 bytes => 64 (0x40))
0000 - 00 3e 03 03 52 fd 41 af-09 0b 96 d6 c4 01 c2 1b .>..R.A.........
0010 - eb e9 23 71 93 a6 1b 78-df 67 17 fe 86 c4 f9 82 ..#q...x.g......
0020 - 53 4f 36 09 00 c0 30 00-00 16 ff 01 00 01 00 00 SO6...0.........
0030 - 0b 00 04 03 00 01 02 00-23 00 00 00 0f 00 01 01 ........#.......
<<< TLS 1.2 Handshake [length 0042], ServerHello
02 00 00 3e 03 03 52 fd 41 af 09 0b 96 d6 c4 01
c2 1b eb e9 23 71 93 a6 1b 78 df 67 17 fe 86 c4
f9 82 53 4f 36 09 00 c0 30 00 00 16 ff 01 00 01
00 00 0b 00 04 03 00 01 02 00 23 00 00 00 0f 00
01 01
SSL_connect:SSLv3 read server hello A
So, as you can see this is way before the handshake is close to done.
From what I can tell, our clients initiate the handshake (cleinthello) and sometimes get silence on the wire.
I've already tried upgrading openssl, with no change. And again, this is only connecting to this one provider out of this one datacenter.
I'm down to some sort of networking issue filtering outgoing SSL traffic in some way, but I have no idea why that would be happening.
Any thoughts on where to go next in the troubleshooting process would be much appreciated. Thanks.
edit: Tried multiple ciphers and can reproduce with all, leading me again to possible network issue.
edit: Similar results with gnutls:
ifx14:/home/cadre/stresler# gnutls-cli -d 9 DOMAIN.DOM
Resolving 'DOMAIN.DOM'...
Connecting to 'X.X.X.X:443'...
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x1a11a60]: Sending extension CERT_TYPE
|<2>| EXT[0x1a11a60]: Sending extension SERVER_NAME
|<3>| HSK[0x1a11a60]: CLIENT HELLO was send [131 bytes]
|<4>| REC[0x1a11a60]: Sending Packet[0] Handshake(22) with length: 131
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a11a60]: Sent Packet[1] Handshake(22) with length: 136

This is old and already answered, but we suffered the same exact issue and the cause was different.
The key was to sniff traffic on our edge router, where we saw ICMP messages to the server (GitHub.com) asking for fragmentation. This was messing the connection, with retransmissions, duplicated ACKs and so.
The ICMP packet had a field, MTU of next hop with a weird value, 1450. The usual value is 1500.
We checked our router and one of the interfaces (an Ethernet tunnel) had this value as MTU, so the router was taking the minumum MTU of all interfaces as next hop. As soon as we removed this interface (it was unused), the SSL handshake started to work again.

As I can see, the client hello has one byte to much on position 00cb: the 0xFF should not be there. So the following bytes data cannot be read correctly...
00c0 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 6d ...............m
Not sure, but it seems to be a bug in openssl, so a firewall or web proxy ignores the request.

For folks who come across this issue, I created a checklist:
Make sure all TLS versions are enabled in Internet Explorer (This is for testing. You can later disable the unsecure versions once you find out the root cause)
Check the registry keys below to make sure what you set in Internet Explorer is applied at registry level. If there are working and non-working servers, mirror the working server’s settings HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Collect a network trace from the client side. Check if the client and server are agreeing on a cipher suite. If they are not, make sure the client uses the cipher suites the server is trying to use. The Group Policy setting is below Computer Configuration > Administrative Templates > Network > SSL> Configuration Settings > SSL Cipher Suite Order
If the issue sill exists, look for any network device (proxy, firewall, load balancer etc.) in between that might be blocking TLS traffic
Check the website binding in IIS. Make sure the certificate is valid and the port is set to 443
Make sure the port 443 is listened in the server (netstat -an -p TCP | find /I "listening"). More details: Port 80 and 443 are not listened in IIS server
Change the port number to 444 and test website. If it is accessible, it means there is a software blocking or overwriting 443 port. More details
Disable Windows Firewall (If it works, you can enable it back and set up rules accordingly)
Look for any third-party applications such as antivirus or endpoint protection software in the server such as Symantec Endpoint Security and Symantec Data Center Security Server Agent (Based on this document, Security Server Agent uses port 443). Uninstall them (Don’t just disable. Uninstall completely. If it works, you can install them back and configure them accordingly)
Check if there is any Microsoft software that is using port 443. Applications like SQL Server Reporting Services (SSRS) and Windows Admin Center might interfere the port 443. An example
Source: The missing Server Hello in TLS handshake (ERR_SSL_PROTOCOL_ERROR

Well, I had a similar problem. SSL handshake terminated with error right after ClientHello. It turned out the server required stronger ciphers than I had installed so I had to install the Java Cryptography Extension (JCE) (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html).
More interestingly, we had the very same problem on a server and we had the jars for JCE there but some older version so it suffered the same problem. Replacing them with the newest version solved the issue.
BTW, do you know how to get required server ciphers? Or better compare the client and server ciphers? So one would immediately see the mismatch.

Develop Reference

r css asp.net wordpress firebase qt symfony nginx http apache-flex