| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
a list of Certificate_Stores instead of a list of actual certs,
allowing for instance the ability to reference a DB cert store without
actually pulling all the certs into memory.
Add Certificate_Store::all_subjects which returns the DNs of all
contained certificates.
|
|
|
|
| |
Only check it if the cert is otherwise valid.
|
| |
|
|
|
|
|
|
| |
X is true" and "assertion X is false". Convert all of them to the form
"assertion X is true" thus making it clear what it is that we are
attempting to assert by testing the expression provided.
|
| |
|
|
|
|
|
| |
Fix some bugs that triggered if DEFAULT_BUFFERSIZE was either too
small or an odd size.
|
|
|
|
| |
style cast in secmem.h
|
|
|
|
|
|
| |
using a custom allocator. Currently our allocator just does new/delete
with a memset before deletion, and the mmap and mlock allocators have
been removed.
|
| |
|
| |
|
|
|
|
| |
nothing meaningful to compare to.
|
|
|
|
|
|
| |
Add SRP hooks in the examples
Fix next protocol support in the tls_server example.
|
|
|
|
|
|
|
|
|
|
|
| |
manager is being used, it could be easily used for session tickets as
well, and if it's not the generate-on-first-call technique is easy to
write.
Avoid offering the session ticket extension if we know we don't have a
key. For one thing it will cause us to avoid using stateful sessions,
but additionally OpenSSL 1.0.1 is very intolerant of empty
NewSessionTicket messages so definitely worth avoiding when we can.
|
|
|
|
|
| |
with a default implementation that creates a new random key on the
first call.
|
|
|
|
| |
lot more work before this can be deployed.
|
|
|
|
| |
up a PSK from an identity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
credentials server to return a new copy each time which is slow and
mostly pointless. Instead, specify that the key remains owned by the
credentials manager.
This is theoretically an issue if you have thousands of keys to
manage; the credentials server doesn't actually know when they have
gone out of scope until its destructor runs. So it could be forced to
use a lot of memory in the meantime. I'm not sure that this is a case
worth optimizing for, at least until someone comes along who actually
has this as a problem.
|
|
|
|
|
| |
and will choose one depending on which ciphersuites the client
offered.
|
|
|
|
|
|
|
|
|
| |
checking, allowed client auth CAs, etc than the policy class. With
this change, most users won't ever need to modify the default policy
which is likely a good thing.
Remove copy and paste of the credentials manager implemenation in the
examples.
|
| |
|
|
what certs, keys, etc are available to the app. Needs polishing but it
seems like it should be sound.
|