I recently needed to configure CocoaHttpServer, which we're using in our application with success, to handle HTTPS connections coming from a client application (running on Android devices). This is fine - there is copious sample code which allows for this, and we were able to enable the secure server without issue.
In practice we were seeing incredibly long SSL negotiation phases while the client was doing its handshaking with our server - upwards of 70 seconds.
Through a long series of searches, I found that the delay was because of the calculation of Diffie-Hellman parameters used by default when SSL is enabled in CFSocket. This thread is where I first started to find the answer to my issue.
To match what our Windows server was doing (using a less-secure SSL cipher) I needed to set the cipher explicitly on the Mac, which isn't easy when using AsyncSocket as a wrapper for the socket communications.
Our Windows server was using:
TLS_RSA_WITH_RC4_128_MD5 )(0x04)
RC4 128 bits MD5 RSA
Our Macintosh server was using:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x039)
AES 256 bits SHA-1 Ephemeral Diffie-Hellman key exchange using RSA certificate
The difference in "security" is large, but likely not worth the effort/computation/delay that we were seeing. Security Theater?
Please note that there are different ciphers that can be chosen - I chose to use the same one as our Windows implementation for consistency.
With information from another question mentioned above, I figured out how to set the cipher for CFSocket to use the same as Windows, and the code appears to be now quite a bit better - like it really works! CFSocket isn't directly exposing the SecureTransport support, which makes this kind of hard, but defining a particular key makes it work nicely.
For posterity, here's the code I've added to -onSocketWillConnect: in our HTTPConnection class:
// define this value; it isn't exposed by CFSocketStream.h
const extern CFStringRef kCFStreamPropertySocketSSLContext;
...
CFReadStreamRef stream = [sock getCFReadStream];
CFDataRef data = (CFDataRef) CFReadStreamCopyProperty(stream, kCFStreamPropertySocketSSLContext);
// Extract the SSLContextRef from the CFData
SSLContextRef sslContext;
CFDataGetBytes(data, CFRangeMake(0, sizeof(SSLContextRef)), (UInt8*)&sslContext);
SSLCipherSuite *ciphers = (SSLCipherSuite *)malloc(1 * sizeof(SSLCipherSuite));
ciphers[0] = SSL_RSA_WITH_RC4_128_MD5; // Basic cipher - not Diffie-Hellman
SSLSetEnabledCiphers(sslContext, ciphers, 1);
I hope this helps anyone working through the same issue as I - I'd be happy to share some more code and advice if needed.
For what it's worth, I contributed a patch to CocoaAsyncSocket about a week before you had this issue. Sorry that I didn't notice your question back then. :-)
Related
For the purpose of debugging I am looking for a way to print the few important contents of the SSL structure in a human friendly way. Does a function already exist in the openssl libraries to do that?
The SSL handshake is failing in my custom private key method provider in some cases and I was looking for ways to print the SSL parameters exchanged on the connection so far.
For eg., TLS version, cipher chosen, etc
I'm trying to bring an old TLS 1.0 implementation (that I did not write) up to date to speak TLS 1.2.
As a first step I integrated the TLS 1.1 change of putting the plaintext initialization vector in the record. That was no problem. It seemed to work well enough that I could read https://example.com in TLS 1.1, as well as SSL Labs viewMyClient.html.
Then I adapted to the TLS 1.2 change of the pseudorandom function to (for most practical purposes) P_SHA256 instead of the (more complex and bizarre) half and half MD5/SHA1 rigamarole. I did it wrong the first time and got an invalid MAC error, but it was more or less a typo on my part and I fixed it. Then the invalid MAC error went away.
But despite that, after sending the ClientKeyExchange->ChangeCipherSpec messages, I'm getting a "Decrypt Error" back from the server(s) (same Alert regardless, https://google.com or anything I try). I gather the ChangeCipherSpec message is encrypting just one byte, putting it into a message with padding and the MAC, etc.
If I tweak the MAC randomly by one byte, it goes back to complaining about invalid MAC. What confuses me is that the MAC itself is encrypted as part of GenericBlockCipher:
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; // <-- server reads this fine!
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
UPDATE: FWIW, I've added a Wireshark log of the failing 1.2 read of https://example.com, as well as a log of a functioning 1.1 session running what is the same code, not counting the P_SHA256 MAC update:
http://hostilefork.com/media/shared/stackoverflow/example-com-tls-1.2.pcapng (fails)
http://hostilefork.com/media/shared/stackoverflow/example-com-tls-1.1.pcapng (succeeds)
So, what exactly is it having trouble decrypting? The padding seems correct, as if add or subtract 1 to the byte I get an invalid MAC error. (The spec says "The receiver MUST check this padding and MUST use the bad_record_mac alert to indicate padding errors.", so that is to be expected.) If I corrupt the client-iv in the message from what I used to encrypt (just put a bad byte in the transmitted version), doing so also gives me Bad Record MAC. I'd expect that to wreck the decryption also.
So I'm puzzled on what could be the problem:
The server demonstrates discernment of valid MAC vs. not, so it must have decrypted. How's it getting the right MAC -and- having a decrypt error?
Cipher suite is an old one (TLS_RSA_WITH_AES_256_CBC_SHA) but I'm just tackling one issue at a time...and if I'm not mistaken, that shouldn't matter.
Does anyone with relevant experience have a theory of how TLS 1.2 could throw a wrench into code that otherwise works in TLS 1.1? (Perhaps someone who's done a similar updating to a codebase, and had to change more than the two things I've changed to get it working?) Am I missing another crucial technical change? What recourse do I have to find out what is making the server unhappy?
There's actually not anything wrong with the ChangeCipherSpec message. It's actually the Finished message that has the problem. It is complaining about the decrypted verify_data inside that message, which is not matching an expected hash (despite the encryption/decryption itself being correct).
But what's confusing in the Wireshark log is that the Finished message shows up on the same log line, but under the name "EncryptedHandshakeMessage" This makes it look like some kind of tag or label describing ChangeCipherSpec, but it's not. That message actually isn't encrypted at all.
TLS finished packet renamed encrypted handshake message
HTTPS over TLS - encrypted type
From the second link:
In practice, you will see unencrypted Client Hello, Server Hello, Certificate, Server Key Exchange, Certificate Request, Certificate Verify and Client Key Exchange messages. The Finished handshake message is encrypted since it occurs after the Change Cipher Spec message.
"Hoping someone has experience updating TLS 1.0 or 1.1 to 1.2, and might have seen a similar problem due to not changing more than the P_SHA256 MAC and bumping the version number"
They only mention two of the three places that you need to update the MD5/SHA1 combination in the "changes from TLS 1.1" section of RFC 5246:
The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256.
The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used.
(Note: The second applies to certificates, and if you haven't gotten to certificate checking you wouldn't be at that point yet.)
What they don't mention in that section is the third place the MD5/SHA-1 combination changes, which is a hash used in the seed for the verify_data of the Finished message. However, this point is also a change from TLS 1.1, described much further down the document in section 7.4.9:
"Hash denotes a Hash of the handshake messages. For the PRF defined in Section 5, the Hash MUST be the Hash used as the basis for the PRF. Any cipher suite which defines a different PRF MUST also define the Hash to use in the Finished computation."
For a formal spec they're being a bit vague on "hash used as the basis for the PRF" (is it the HMAC or just the plain hash?) But it's the plain hash. So SHA256, unless the cipher suite's spec says otherwise.
(Note also the cipher suite can dictate the length of the verify_data as more than 12 bytes, though none mentioned in the spec do so.)
"What recourse do I have to find out what is making the server unhappy?"
YMMV. But what I did was just build OpenSSL as a static debug library, and linked it to a simple server. Then I added breakpoints and instrumentation to see what it was upset about. (GDB wasn't letting me step into the shared library, for some reason.)
Circa 30-Sep-2018, on a plain linux machine:
git://git.openssl.org/openssl.git
./config no-shared no-asm -g3 -O0 -fno-omit-frame-pointer -fno-inline-functions no-ssl2 no-ssl3
make
The simple server I used came from Simple TLS Server. Compile against the static library with:
gcc -g -O0 simple.c -o simple -lssl -lcrypto -ldl -lpthread
I followed the instructions for generating certificates here, but changed the AAs to localhost
openSSL sign https_client certificate with CA
Then I changed the cert.pem => rootCA.pem and key.pem => rootCA.key in the simple server code. I was able to do:
wget https://localhost:4433 --no-check-certificate
And successfully get back test as a response. So then it was just a matter of seeing where my client caused a failure.
I can think of 2 different situations that creates this problem:
Sending incorrect IV. IV affects only 1st block in decryption of CBC mode, so if your content is more than 16 bytes (AES block size), MAC part of your data will be decrypted correctly.
If you are using incorrect padding structure, you may get error in decryption(because padding verification fails), but content will be decrypted correctly.
I tried posting this on ask.openstack but it has been stuck in the moderator for 5 days now. I thought I'd try here.
I was trying to debug a Nova issue and wanted to decode the SSL / TLS packets being exchanged using Wireshark. Part of the changes I was making was setting Nova up to use SSL / TLS and I wanted to be sure that part of it I had set correctly. I eventually figure out my issues from the various log files but I'm somewhat assuming that being able to watch the network traffic may help in some very difficult cases.
The exchange uses TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at one point. According to this security stackexchannge question, there is a "pre-master secret" or various other terms. I've wrestled with this before in a previous life doing IPSec. Usually you can set debug in the application and it will spew out the secret into the log file. I tried "debug = true" under Default in nova.conf and got lots of debug but no secret. There was two items that looked interesting that were reported as **** in the log: keystone_authtoken.memcache_secret_key and neutron.metadata_proxy_shared_secret. I wasn't sure if those were the secrets I was looking for or not. In this case, I'm looking at the nova-api traffic going to port 8774.
Also, since all of openstack is Python and uses the same "request" and "certifi" packages, it may be possible to generalize this to all of the openstack components.
nova --version report 9.1.1
In our system, virtual hosts configuration is stored in redis. During connection setup, when the SNI is received, we would like to query redis for the correct certificate and key pair to use for the TLS connection and create a new Context instance with that attached.
The bulk of the code is similar to the accepted answer here: Twisted listenSSL virtualhosts
The issue we are facing is that, since accessing the certificates involves an additional network operation, we would like to make the set_tlsext_servername_callback function return a deferred.
Is there a way to tell Twisted/pyOpenSSL to wait until the deferred fires?
Edit: I found this link which seems promising, but falls short of providing a solution: https://mta.openssl.org/pipermail/openssl-dev/2015-January/000480.html
You can find an example of Twisted and SNI here: https://pypi.python.org/pypi/txsni. I would really, really like that callback to be able to take a Deferred. I think that the way to do this would be to pause the underlying transport from delivering any further bytes either in or out (stopReading/stopWriting) and then resume when the Deferred fires, after doing the rest of the SNI dance. However, I'm not even sure if this is possible with OpenSSL, because the SNI is received with the rest of ClientHello and you may need to be able to react immediately to serve the correct certificate. In this worst-possible-case scenario, you could feed the first chunk of bytes you receive into a dummy memory-BIO, wait for the TLS handshake, throw it away and never deliver any generated responses, and then don't initialize your "real" sub-transport until you've decided on which context object to use.
Hope this helps - and if you figure it out, please contribute a patch to TxSNI or Twisted!
I am updating the OpenSSL libraries in my application to version 1.0.2c.
This version supports the TLS 1.0, TLS 1.1 and TLS 1.2 as well the SSL 3.0. I would like to configure my application to automatic negotiate the highest version possible.
I have read the documentation provided in https://www.openssl.org/docs/ssl/SSL_CTX_new.html which says that the TLS_method, TLS_client_method and TLS_server_method methods can do this.
But in the Windows distribution (avaliable in https://www.openssl.org/related/binaries.html) the ssleay32.dll does not export the methods TLS_method, TLS_client_method and TLS_server_method. Other methods, like TLSv1_method, TLSv1_1_method and TLSv1_2_method are exported. However those only accepts a specific version.
What method should I use in order to make the version negotiation automatic? Or should I choose the version at runtime?
I would like to configure my application to automatic negotiate the highest version possible.
Use the following code from SSL/TLS Client on the OpenSSL wiki:
const SSL_METHOD* method = SSLv23_method();
if(method == NULL) handleFailure();
ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();
/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
It gets you "TLS 1.0 and above".
Note the lower bound really provides a TLS record layer version of TLS 1.0. The upper bound is the TLS client version of TLS 1.2. The record layer carries the encrypted payload. And the SSLv23_method gets you a ClientHello in a particular format (for SSLv3 and above).
Implying the lower bound from the record layer version is how most folks use it, but its not how the standard is written. And the TLS Working Group appears to refuse to provide it that way. The effective argument given is "suppose a client want to use TLS 1.0, 1.2 and 1.3, but not 1.1". I don't know anyone who drops a protocol version like that, so its just a strawman to me.
You can read more about it at one of the answer to Check Server security protocol using openssl.
Related, you should use this cipher suite list:
const char* const PREFERRED_CIPHERS = "HIGH:!aNULL:!MD5:!RC4";
res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(res != 1) handleFailure();
As a matter of fact, RSA key transport is no longer favored by the security community, so the following may even be a better choice when using a certificate with a RSA key:
"HIGH:!aNULL:!MD5:!RC4:!kRSA";
The cipher string will provide mostly contemporary security, and it will avoid the obsolete cryptography warning.