TLS session manager #630
TLS session manager #630
Conversation
|
@ocheron You might be interested in this. |
|
@snoyberg Please hold merging until a new version of |
Session resumption is certainly desirable and the analysis you reference is really interesting. If I understand correctly, security concerns come only when using session tickets or 0-RTT, which we don't have currently in tls. Session manager API could have two functions |
|
@ocheron Thank you for your suggestions. |
|
@ocheron Your idea is really cool. I will implement |
|
|
||
| ---------------------------------------------------------------- | ||
|
|
||
| -- | Creating a in-memory session manager. |
There was a problem hiding this comment.
Thanks. Fixed.
| cons :: Int -> Item -> DB -> DB | ||
| cons lim (k,t,v,Add) db | ||
| | Q.size db == lim = case Q.minView db of | ||
| Nothing -> Q.insert k t v Q.empty -- not happens, just in case |
There was a problem hiding this comment.
How about adding an assert False here?
There was a problem hiding this comment.
Do you refer to Control.Exception.assert?
If so, what the second argument should be?
There was a problem hiding this comment.
Yes, that's what I meant. I'd leave the second argument as the current right-hand side of the -> as a fair fallback.
There was a problem hiding this comment.
Thanks and done.
|
|
||
| clean :: DB -> IO (DB -> DB) | ||
| clean olddb = do | ||
| currentTime <- getCurrentTime |
There was a problem hiding this comment.
It may be better to use a monotonic clock from the clock package to avoid clock skew issues.
(And yes, that same advice probably applies to some of my reaper logic elsewhere like http-client.)
There was a problem hiding this comment.
What constructor of Clock should I choose for getTime for this purpose?
Realtime?
| @@ -129,6 +131,15 @@ data TLSSettings = TLSSettings { | |||
| -- Default: Nothing | |||
| -- | |||
| -- Since 3.2.2 | |||
| , tlsSessionManagerConfig :: Maybe SM.Config | |||
| -- ^ Configuration for in-memory TLS session manager. | |||
| -- If Nothing, 'TLS.noSessionManager' is used. | |||
There was a problem hiding this comment.
Why wouldn't we default to using some basic configuration? Is there a downside to turning on a manager by default?
There was a problem hiding this comment.
- It changes the current behavior of warp-tls (i.e. allowing session resumptions).
- It requires more memory than the current.
So, I think that users should explicitly set this parameter.
kazu-yamamoto
force-pushed
the
tls-session-manager
branch
from
a11beb4 to
821b6f0
Compare
|
@snoyberg A new |
kazu-yamamoto
force-pushed
the
tls-session-manager
branch
from
821b6f0 to
f68fe53
Compare
|
I have removed the patch for warp-tls so that all tests should pass in CI. |
|
Thank you! |
|
A pleasure :)
…On Tue, Jul 4, 2017 at 5:27 AM, Kazu Yamamoto ***@***.***> wrote:
Thank you!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#630 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AADBB1MH8e1uk3H-SpuzkvEIAlVDogVeks5sKaMHgaJpZM4OI4gK>
.
|
|
|
I would like to include an in-memory TLS session manager to
wairather than totlsbecause it requiresauto-updateand it is used inwarp-tls.I'm implementing this, rather than the mechanism of stateless session tickets, based on this analysis and Single-Use Tickets. In short, I would like to provide anti-replay features.
Please read the documentation of this package (i.e. the beginning of the
SesssionManagers.hs).This package can be used for TLS 1.2 or earlier, hence this PR includes the modification of
warp-tls. This is also used for TLS 1.3 which is implemented currently as one of my topic branch.Any suggestions are welcome.