I was pleased to note that support for SessionTicket (RFC 4507) was
added into the OpenSSL 0.9.9 tree couple of weeks ago. This
implementation seems to include session ticket use as specified in RFC
4507 which alone is not enough for supporting EAP-FAST (RFC 4851) since
EAP-FAST takes care of
It's probably the fault of Java, calling a non-thread-safe OpenSSL
method from multiple threads. See
http://www.odi.ch/weblog/posting.php?posting=432
__
OpenSSL Project http://www.openssl.org
Marek Marcola wrote:
Hello,
are there some available settings to build openssl for small footprint
applications and devices?
I mean to get a smaller library like matrixssl [1] and strip thing and
module out someone might not need ?
In my personal opinion: no.
(This is why MatrixSSL
David Schwartz wrote:
What return value makes sense with your model? If it says it sent
everything, you will not call into SSL again unless you have something to
write or expect to read something. If neither is the case, when will OpenSSL
get the chance to send those C bytes left over?
If the
If the SSL implementation works in this way then trying to shoe-horn SSL
into a similar 3 argument API as the kernel was a bad design decision.
I agree. In other words, the nature of SSL demands a more complex API than
TCP.
Its probably a bit late in the game to go changing the SSL_write()
David Schwartz wrote:
Honestly I think a better job of mimicking TCP's semantics is preferable.
OpenSSL should be able to handle its own send buffer flushing and receive
buffer filling, in the background without me having to ask it, just like TCP
does.
This can easily be done with OpenSSL
Darryl Miles wrote:
int SSL_write(SSL *ssl, const void *buf, int buflen, int
*committedlenptr);
This is an interesting suggestion. This way if *committedlenptr was
returned
as 0 or as buflen then the application is free to change buf/buflen/contents
at will for the next call without worry of
I think a library should be capable of making SSL look as much like TCP
as
possible and that this should probably be the default behavior.
I agree the compatible model should exist, the jury is out on the
default behavior. Your kernel-socket-like paradigm should be just a
usage
Mark Pietras wrote:
you’ll have the general population of application writers up and running
with much less support/headache. The 10% (or whatever) that are worried about
a memcpy or two (yes I’m oversimplifying) can use the advanced methods.
But it requires threads and OpenSSL does not
