Provide access to TLS channel binding data from a SSLContextRef and NSURLRequest/NSURLSession
| Originator: | wiml | ||
| Number: | rdar://18517632 | Date Originated: | 01-Oct-2014 |
| Status: | Open | Resolved: | |
| Product: | Product Version: | ||
| Classification: | Reproducible: | Always |
Summary: Several modern authentication protocols, such as SCRAM (rfc5802) and enrollment-over-TLS (rfc7030), make use of TLS channel binding (see rfc5056 and rfc5929) to improve security. In order to implement these, the client needs access to some data from the SSL negotiation process (specifically the Finished messages). There is currently no way to retrieve that data. Request: Two additional APIs: 1. Have some way to retrieve that data from an SSLContextRef. 2. Some way to gain access to the SSLContextRef from the NSURLRequest when it is reading from its HTTPBodyStream, or a KVObservable property on the NSURLRequest which can be used to update the HTTPBody when the request is about to be sent on a new channel, or a delegate method on NSURLSession that can be used to update this information, or something like that. Motivation: Getting the data from a plain SSLContextRef is needed for non-HTTP protocols that might be using SCRAM. Getting the data from a NSURLRequest is needed for HTTP-based protocols; a request might be sent multiple times (re-authentications, redirects, etc.) so it is necessary to be able to update the body when the request's channel changes. Concern: It should also be possible to alter a request's headers according to the TLS channel binding information, but I don't see a good way to shoehorn that capability into the NSURL loading machinery. Steps to Reproduce: n/a Expected Results: n/a Actual Results: functionality is not there Version: iOS 8, OSX 10.10
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!