It cannot connect with SSL certification since last update.

[bluefish625]

It cannot connect with SSL certification since last update.

Last week, We checkout the source code and test it using TestChat project to connect our server through wss://. It's work perfectly!

But, We checkout a new version today. It not work. We merge the source code found it has been changed.

The error code is:

Error Domain=SRWebSocketErrorDomain Code=2133 "Invalid Sec-WebSocket-Accept response." UserInfo={NSLocalizedDescription=Invalid Sec-WebSocket-Accept response.

[nlutsenko]

Hey @bluefish625, thanks for the report!
Let's debug this together!

• Is your server is using self-signed SSL certificates?
• Any chance you can specify the commit you had before, so we can bisect?
• Overall, anything I can hookup to and test against would be just extremely useful!

[nlutsenko]

Just tested this by running against this public URL: wss://echo.websocket.org,
which is indeed using wss and everything works like a charm!

[nlutsenko]

Also, if you are using a self-signed certificates or a certificate that doesn't validate - I would recommend trying to enable allowsUntrustedSSLCertificates when constructing your SRWebSocket instance.
For example:

NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:@"wss://echo.websocket.org"]];
SRWebSocket *webSocket = [[SRWebSocket alloc] initWithURLRequest:request
                                                       protocols:nil
                                  allowsUntrustedSSLCertificates:YES];

[bluefish625]

@nlutsenko We use CA certification and do not allowsUntrustedSSLCertificates.(allowsUntrustedSSLCertificates = NO;)

This is my Request:

• (NSURLRequest *)wssRequestWithURL:(NSURL *)url
  {
  NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:url];

  NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"CA_socketCertificate" ofType:@"cer"];

  if ([[NSFileManager defaultManager] fileExistsAtPath:cerPath])
  {
  NSData *certData = [[NSData alloc] initWithContentsOfFile:cerPath];
  CFDataRef certDataRef = (__bridge CFDataRef)certData;
  SecCertificateRef certRef = SecCertificateCreateWithData(NULL, certDataRef);
  id certificate = (__bridge id)certRef;

  [request setSR_SSLPinnedCertificates:@[certificate]];
  

  }

  return request;
  }

In my code, we set PinnedCertificates. The @"CA_socketCertificate" is a CA Certificate.

[bluefish625]

@nlutsenko If do not call [request setSR_SSLPinnedCertificates:@[certificate]]; (The property of SR_SSLPinnedCertificates is nil). It work perfectly.

What's wrong with us?

But, In old code, we set SR_SSLPinnedCertificates too. It work well.

[bluefish625]

@nlutsenko I think maybe I'm wrong. We use CA certificate. So we should not set pinnedCertificate?

[bluefish625]

@nlutsenko Oh, I'm forget to say thanks. Thanks for reply. Thanks very much.

[nlutsenko]

Aha! That helps a lot! Using pinned certificate is actually a great security measure and you absolutely should continue doing it.

Taking into account that #395 added proxy support, the way we open streams actually changed and I bet it needs the same implementation as we have in the base SRWebSocket for pinned cert validation. Right now it has the chain validation turned on for everything, even if you use a pinned cert.

Implementing a fix looks easy, but since it's going to take some time for me to do the setup to validate this, I would recommend either rolling back to the last released version (which is very stable) or looking into -stream:handleEvent: on SRWebSocket and copying some code over to SRProxyConnect in addition to _updateSecureStreamOptions on SRWebSocket that sets up the SSL Settings (which is crucial in case of pinned certs).

[bluefish625]

@nlutsenko Thanks very much. I think rolling back to the last released version is a good choice.
Looking forward to the next release. O(∩_∩)O

[nlutsenko]

The fix is actually simpler than I thought.
It has something to do with our internal architecture of the state being treated as fully connected only after cert validation succeeded in case when pinned certificates are used.
Submitting a fix in a bit, should be available later today/tomorrow.