[cronet] SSLSession cache
Reported by
kangzhan...@gmail.com,
Mar 22 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2679.0 Safari/537.36 Steps to reproduce the problem: N.A. What is the expected behavior? Right now Cronet doesn't persist SSL session data on disk. This feature request proposes that we have an optional disk cache to persist the SSL session data(E.g. the session ticket, server etc), to improve the SSL resumption rate. This may not be useful for Chrome, since the browser tends to talk to different hostnames and it certainly adds complexity to the stack. But it may help third-party apps a lot, since 1) these apps usually talk to the same hostname for API requests 2) android apps cold start very often and would lose the in-memory session cache easily. It would be nice to have this feature as optional, so that different apps can opt-into it. See following links about the Android system implementation and how it works. http://developer.android.com/reference/android/net/SSLSessionCache.html http://developer.android.com/reference/android/net/SSLCertificateSocketFactory.html https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/ClientSessionContext.java https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/AbstractSessionContext.java https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/OpenSSLSocketImpl.java What went wrong? N.A. Did this work before? N/A Chrome version: 51.0.2679.0 Channel: dev OS Version: OS X 10.11.3 Flash Version: Shockwave Flash 21.0 r0
,
Mar 22 2016
mef: Leaving you as Cronet TL to make a decision, but this is something I'm strongly opposed to and feel strongly we should WontFix on security grounds. I can follow-up with you separately, but we've repeatedly ruled this out on security grounds.
,
Mar 22 2016
rsleevi: Thanks for your comments, I'll be happy to discuss. I presume that the need for this will be somewhat alleviated by 1-RTT handshakes in TLS 1.3.
,
Mar 22 2016
Cool, thanks guys! Please keep me posted about the decision here. Not sure what security concern rsleevi has, but Android already has sandboxing and the content we cached should be safe unless the phone is rooted/hacked. mef: Yeah, this will be less big deal with 1-RTT or 0-RTT handshake.
,
Apr 26 2016
Closing this as WontFix on security grounds. Having longer process lifetime is the only safe way to maintain SSL Session. There is a separate work being done to persist certificate verification results, which should reduce connection overhead.
,
Apr 26 2016
Removing the BlockedOn, since the work for this bug won't actually proceed, and thus isn't blocked on Issue 590875 happening. |
||||
►
Sign in to add a comment |
||||
Comment 1 by rsesek@chromium.org
, Mar 22 2016Labels: -OS-Mac OS-Android