Topic: CyaSSL as OpenSSL Alternative; Compatibility Layer (old forum post)
Hello I have few problems to report with cyassl. 0.9.6
Problem 1:
Default setting for SSL_CTX_set_verify per OpenSSL should be SSL_VERIFY_NONE, and this is not what is set in cyassl. See this for refernce: http://publib.boulder.ibm.com/infocente … erify.html
Problem 2:
Using cyassl with HTTP 1.0 connection. In this case client needs to poll until connection is closed. The problem is that on connection end SSL_read should return 0 and in cyassl it always returns error -208.
After some looking through the code I found out that the problem seems to be in recieve function that treats connection closure as error, and connection reset which is the error as not error. This seems to be incorrect.
I would greatly appreciate if you could fix both issues.
#
touskaProject Admin
[Avatar]
2008-05-05 20:28:41 UTC
Hi Boris,
Problem 1: I can't in good conscience default CyaSSL's behavior to SSL_VERIFY_NONE. We only provide a compatibility layer and it's not perfect. In fact, I'd argue our choice is much better. Why have a default behavior for secure sockets that provides no more real security than plain sockets? Why place the burden on the user to do all this checking themselves? And, if you want to mimic OpenSSL behavior we allow this, you just have to be explicit. I haven't heard a good argument to change this policy yet, but feel free to try.
Problem 2: Thanks for the report. You are right, during SSL_read (but not the handshake) socket closure should return 0 and not an error. Even though the standard says this is an error (SSL shutdown should occur first) I'll go along with the OpenSSL man page on this one. But I think socket reset (usually machine reset or network reset and thus not able to do an SSL_shutdown) should also return 0. So I'm going to leave reset as it is unless you can tell me why this is incorrect. I'll check in the closure change by the end of the day.
Thanks for the feedback and reports,
Todd
#
borkraAccepting Donations
[Avatar]
2008-05-06 01:29:53 UTC
Hi Todd,
thanks for fixing issue #2.
Let me try to lay down my case for changing the behavior for both problems.
Problem #1:
Yes you are right default none is insecure. But the problem is if default is not none, you cannot establish SSL connection by default. Certificate was never validated and connection was aborted (and this is a real problem). So as a result I had to spend few hours chasing SSL API trying to figure out why and what is the issue. A lot of people would just cast your library by that time and move on elsewhere. Mimicking OpenSSL brings a lot of value to your library as one could replace existing code using OpenSSL with your stuff in 5 min there is a lot of value in that.
Problem #2:
If connection was reset there is no connection any more, so what SSL_shutdown going to do? Try to reestablish the connection and send a shutdown message? Chances are server will not even link 2 connections together. What's gone is gone...
And after looking into your code SSL_shutdown does not even try to reestablish the connection. So I am completely confused what is the purpose for all of this?
Sockets as far as I know close connection when reset received, so you cannot send anything on this socket any more until connection reestablished.
#
borkraAccepting Donations
[Avatar]
2008-05-06 01:48:35 UTC
Todd,
More on problem #2:
I forgot to mention, that if I am doing HTTPS 1.0 and received 0 - connection closed it means that all data recived, on the other hand if I got error that means I did not get any data or got partial data, my response to this 2 events would be completely different. I 1st case I would process the data in the 2nd case I would ignore it. I hope you see the difference.
#
touskaProject Admin
[Avatar]
2008-05-06 19:21:44 UTC
Connection closed doesn't necessarily mean all data received in SSL. A conforming stack (and user) will call SSL_shutdown after they've sent all data, only then will you know for sure. A socket closure without SSL_shutdown could merely mean an exception handler was called, or the OS was doing cleanup on process shutdown after a fatal error (while data was still buffered to be sent).
The point I was trying to make was that both connection closed and reset are technically errors if the first peer to stop doesn't first send SSL_shutdown(). Though I agree that partial data is an error. I'll try to make sure that CyaSSL always returns an error in this case. BTW, the reason I have reset behave that way is a report from an embedded SSL user asking for more OpenSSL compliance. Is it your understanding that OpenSSL doesn't return 0 on socket reset for an SSL_read?
Thanks for the help.
#
touskaProject Admin
[Avatar]
2008-05-06 19:31:34 UTC
1: Well, that's my failure for not properly (or more easily) documenting the change. Which ever way this ends up, I need to document this behavior better. That's a good point for compliance, but maybe if I have comments at the beginning of the README, around SSL_connect, and in the examples users won't run into this problem in the future. If they do, you're right, I should change it, but I should document just as much about how this is unsafe and how they should use it.
2: I didn't explain SSL_shutdown() very well I think. I was trying to point out that proper SSL shutdown/closure is to call SSL_shutdown(), not close the socket first. I don't try to send an SSL_shutdown if the connection is closed because it's a socket error to try that, it's just to avoid SIGPIPE. But if the connection isn't closed, then I try to send an SSL_shutdown message even if the peer hasn't (which isn't required but is recommended).
See the rest of my comment on the next post, thanks.
#
borkraAccepting Donations
[Avatar]
2008-05-07 04:50:30 UTC
Todd,
regarding SSL_read. I guess I did not explain what I am trying to do correctly.
I am trying to implement HTTPS 1.0 protocol. It is HTTP 1.0 over SSL tunnel.
HTTP 1.0 works as following: you send a request through socket send (1 or many and then wait for reply) reply message is completed when connection is gracefully closed (socket read returns 0, otherwise http transaction failed). You can read RFC 1945 for information on HTTP 1.0.
In the previous messages I described to you how HTTPS 1.0 was implemented using OpenSSL. And it is working flawlessly for years. I am not clear though how do you propose to implement HTTPS 1.0 over cyassl, this connection reset seems to be a problem. As I do not understand how to distinguish graceful connection closure from not graceful one, as per HTTP 1.0 graceful closure signifies the transmission complete event.
#
borkraAccepting Donations
[Avatar]
2008-05-07 06:21:10 UTC
Todd,
Tried your latest CVS code and got a problem. Cannot establish SSL connection. The error happens in the new DoServerKeyExchange. On line
if (messageTotal > sizeof(messageVerify))
return BUFFER_ERROR;
If you would like to try it yourself the host is: kc-in-f125.google.com
#
touskaProject Admin
[Avatar]
2008-05-07 18:58:22 UTC
Thanks for the report, I've checked in a fix. I'd never seen Ephemeral DH greater than 1024 bit before, I've added support for up to 2240 bit. If people start going to 3072 or higher I guess I'll make the buffer dynamic, I've just tried to avoid doing that with CyaSSL.
#
touskaProject Admin
[Avatar]
2008-05-07 19:03:53 UTC
Fair enough, let's see if the reset on read is really the problem. Can you change a line in ReceiveData() in cyassl_int.c
from:
if (ssl->options.connReset || ssl->options.isClosed)
to:
if (ssl->options.isClosed)
If that better matches OpenSSL behavior then I'll check it in.
Please let me know if that works, thanks.
#
borkraAccepting Donations
[Avatar]
2008-05-07 23:38:36 UTC
Hi Todd,
Yes thank you, change in cyassl_int.c does make it work.