Re: Reset contexts of NSURLConnection
Re: Reset contexts of NSURLConnection
- Subject: Re: Reset contexts of NSURLConnection
- From: Ken McLeod <email@hidden>
- Date: Fri, 22 Apr 2011 10:35:01 -0700
On Apr 22 2011 09:01 AM, Andrey wrote:
> Is there way to reliably reset SSL persistent context used by NSURLConnection class?
> It keeps persistent SSL automatically and it's very nice in most of cases, but sometimes it's getting
> stuck in those persistent SSL sessions between connections and I can't find a reliable way to reset it.
> I'm feeling like I'm missing something obvious, but releasing object doesn't do the trick.
There is a session cache maintained by Secure Transport, the SSL implementation used by CFNetwork (which in turn is used by NSURLConnection.) Secure Transport has an API to control whether a session is resumed: SSLSetPeerID(). What you're running into here is the fact that CFNetwork always calls this API on your behalf, using the server name and port number as the unique session ID. If you had opened a prior connection to the same server:port, the previous session's negotiated parameters get reused.
So, to force a new session, you have to either avoid calling SSLSetPeerID (which you can't do, since it's done for you automatically), or call it again with something unique which won't already be in the cache. To do this, you would first have to get hold of the underlying SSLContextRef for the CFNetwork connection.
Unfortunately, the property to get at the SSLContextRef (kCFStreamPropertySocketSSLContext) is not in a public header. That property contains a CFDataRef whose value is actually a SSLContextRef.
Quinn came up with an interesting hack to work around the issue, which takes advantage of the fact that a trailing '.' can be added to a DNS host name. So if you first connected to "www.apple.com:443" and now want a differently-authenticated connection, you can connect to "www.apple.com.:443" and that peer ID will not match the prior one. Obviously, this will only give you two possible sets of session parameters for a given host:port combination, but in a typical case you only need two connections, unauthenticated and authenticated.
There is a bug tracking the need for control over session resumability (8957312) but please write up one of your own to help accelerate matters.
-ken
>
> More specifically - if I get to some https URL it asks for client cert. If I ignore the request with
> continueWithoutCredentialForAuthenticationChallenge: server returns status 200 and xml with error in the body.
> Now I'm picking proper certificate and want to reconnect, but server doesn't
> send client cert challenge anymore because SSL session is persistent and it simply returns to previous unauthenticated
> state. A real bummer and I can't work it around reliably - sometimes it goes away on it's own, but may stay this way for pretty long.
> My guess is that the SSL context is global and has some inactivity expiration.
> Just in case - I realize that the server is not behaving properly in this case, but this is irrelevant at the moment.
>
> And similar question about sockets and tcp - how to make sure that all socket associated to some request are really closed and
> I'm guaranteed to have a fresh tcp/http connection to a server?
>
> Thanks!
> Andrey _______________________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden