| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This now requires that the network backend exposes a tls_builder
function, which essentially wraps the former util.sslconfig.new()
function, passing a factory to create the eventual SSL context.
That allows a net.server backend to pick whatever it likes as SSL
context factory, as long as it understands the config table passed by
the SSL config builder. Heck, a backend could even mock and replace the
entire SSL config builder API.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For this, various accessor functions are now provided directly on the
sockets, which reach down into the LuaSec implementation to obtain the
information.
While this may seem of little gain at first, it hides the implementation
detail of the LuaSec+LuaSocket combination that the actual socket and
the TLS layer are separate objects.
The net gain here is that an alternative implementation does not have to
emulate that specific implementation detail and "only" has to expose
LuaSec-compatible data structures on the new functions.
|
| |
|
|
| |
Same way as with other cipher list options
|
| |
|
|
| |
This enables it to understand protocol = "tlsv1_3+"
|
| | |
|
| |
|
|
| |
colon-separated list, like ciphers (see #879, #943, #951)
|
| |
|
|
| |
tri-state field than a set of options
|
| | |
|
| |
|
|
| |
return them in a table at the end
|
| | |
|
| |
|
