#
[Avatar]
2010-10-01 14:10:05 UTC
Hi! I would like to ask for help with the following problem: I need to reuse the transport layer (TCP socket, currently) doing several (SSL_new, SSL_connect/accept, sending data to and from, SSL_shutdown, SSL_free) sessions one after the other. If both client and server are wolfSSL only (or openssl only), it works flawlessly. But if the client is wolfSSL and the server is openssl (or vice versa), there are problems after the first session. Thank you in advance, Visibilis
#
touskaProject Admin

[Avatar]
2010-10-01 16:56:56 UTC
wolfSSL doesn't support reuse of the underlying connection in the exact same way that OpenSSL does through the use of SSL_shutdown() in two phases. That is something we can change. But I'm curious. If you know you're going to be reusing the underlying connection why not just leave it open in the first place?
#
visibilis

[Avatar]
2010-10-05 13:42:10 UTC
I need this, for example, because I would like to use an external session cache. The cache should be able to work with OpenSSL, as well. I would like to use the cache along the lines of i2d_SSL_SESSION and d2i_SSL_SESSION. One use case would be to start an ssl session, shut it down, and open a new ssl session using the serialized session from the external cache. All using one underlining connection.
#
touskaProject Admin

[Avatar]
2010-10-05 18:22:45 UTC
That's not going to be possible I think. A session cache is implementation specific, there's no standard for what and how to store it. That is, you can't use the same session cache with OpenSSL, gnuTLS, yaSSL etc... Further, wolfSSL doesn't support an external session cache since it's an embedded SSL library intended for embedded use. That's not say it won't in the future but we haven't had any requests for it yet.
#
visibilis

[Avatar]
2010-10-08 13:43:03 UTC
Thank you for your kind reply. Could you give me a hint what I should do to be able to reuse the underlying connection with wolfSSL? Will you implement it, if I ask you nicely?
#
touskaProject Admin

[Avatar]
2010-10-11 21:16:24 UTC
Use wolfSSL on both ends is one solution. Don't call SSL_shutdown on either end may be another. At some point we'll update wolfSSL to handle this situation but we're very busy with customers and potential customers at the moment so I can't give an estimate of when that will be.

#
[Avatar]
2010-07-27 11:31:31 UTC
I am writing client/server that send file using DTLS (wolfSSL). Try with code as in echoserver in example, each time data received, it should re-bind again. Tried not to close socket but still not receive data anymore. Is there able to keep the socket listener?
#
touskaProject Admin

[Avatar]
2010-07-27 16:58:47 UTC
Why are you using DTLS for file transfer? DTLS is typically for streaming applications where missing parts of the data don't matter. If you want the file to be complete you need to use TLS instead. UDP sockets don't listen, though they can connect to an address. Pay close attention to the echoserver and echoclient example. You can run the echoserver in DTLS mode if you build wolfSSL with DTLS with --enable-dtls . Then you can run the echoclient from examples/echoclient with DTLS and exchange a file like this: ./echoclient input where input is a text file with some source code.
#
afelion

[Avatar]
2010-07-28 01:28:32 UTC
in echoserver.c, line 154, server loop: SSL_shutdown(ssl); SSL_free(ssl); CloseSocket(clientfd); #ifdef WOLFSSL_DTLS tcp_listen(&sockfd); SignalReady(args); #endif The socket is re created, and bind on the address again. How to keep the current socket?
#
afelion

[Avatar]
2010-07-29 03:41:11 UTC
Any help? I have problems when handing multi connections to a DTLS server. server: Call recvfrom to listen new connection When a SSL accepted, call SSL_read to retrieve data. If I want to keep that connection for future transfering, the server can not back recvfrom new connections. If I put SSL_read in another thread, and continue bind the socket again, then got error "Address already in use". So how to handle multi clients in UDP server? Thanks in advance.
#
touskaProject Admin

[Avatar]
2010-07-29 04:13:52 UTC
Are you sure you want DTLS? UDP servers are iterative and connectionless. You indicate you want a concurrent connection oriented server, that means TCP and TLS. The example echoserver is iterative, as a UDP server should be. You could try making it concurrent but I think you'll find it much easier to just use TLS instead.
#
afelion

[Avatar]
2010-07-29 04:47:12 UTC
I have read: http://www.net-snmp.org/wiki/index.php/ … tion_Notes and want to do something similar using wolfSSL but have no idea about FIFO BIO.
#
touskaProject Admin

[Avatar]
2010-07-30 03:04:48 UTC
SNMP over UPD makes sense. One questions, one answer... iterative server. No TCP startup or teardown. DTLS over SNMP doesn't make sense, the DTLS handshake has extra steps over TLS negating the benefit of no TCP. And a concurrent server is now needed. The right answer in this case is use TLS. All of the things wrong with DTLS over SNMP are discussed in the link you provide. They're not unique to OpenSSL's implementation, it's just a poor choice. A bad alternative is to have an iterative UDP server get a request, spawn a worker thread with a new port and send that port back to client who then connects with DTLS to the port returned. Many clients, many server worker threads (or whatever). I suggest doing that if you have to use DTLS. wolfSSL doesn't yet allow the user to directly write to the input output buffers. But if you feel like must do that feel free to add the changes. I'll try to help if I can.
#
afelion

[Avatar]
2010-08-22 15:28:35 UTC
Thanks for your answer. Today I have time back to the implementation and have to bother you again. * Server 1. Create an UDP socket, binding on localhost. Create server CTX, SSL. 2. Start new thread, loop forever, using select() to wait new connection: select(fd + 1, &fds, NULL, NULL, NULL); and recvfrom to read UDP connect (echoserver.c) 3. When has a new connection, create new SSL and do SSL_accept. If connection is accepted, and save its SSL, address/port in a connected list 4. Do SSL_read to get data, and call this connection callback to handle the data. 5. Data responded is write to this connection SSL object (SSL_write) 6. Back to select() for new connections. 7. When has another connection (bypass select()), search its address/port in the connected list; if found, get the SSL saved, skip SSL_accept, back to step 4, otherwise, do SSL_accept and add to the list. * Client 1. Create an UDP socket, new client CTX, SSL. 2. Do SSL_connect, if success, start a new thread waiting response data. 3. Send data (SSL_write) in main thread. The above code is worked if I have only ONE client connects to the server, send, recv ok between that client and server. But if I create new client process, SSL_connect always returns error SOCKET_ERROR_E (tried in both Windows, Linux, and NON_BLOCKING mode). Server do not pass the select() waiting for the second client. I used certs files from wolfSSL source, CTX created success * Server: SSL_METHOD *method = DTLSv1_server_method(); SSL_CTX *ctx = SSL_CTX_new(method); SSL_CTX_load_verify_locations(ctx, "ca-cert.pem", 0); SSL_CTX_use_certificate_file(ctx, "server-cert.pem", SSL_FILETYPE_PEM); SSL_CTX_use_PrivateKey_file(ctx, "server-key.pem", SSL_FILETYPE_PEM); * Client: SSL_METHOD *method = DTLSv1_client_method(); SSL_CTX *ctx = SSL_CTX_new(method); SSL_CTX_load_verify_locations(ctx, "ca-cert.pem", 0); Do not know what I missed here
#
touskaProject Admin

[Avatar]
2010-08-23 17:56:22 UTC
You don't specify where and when you're calling connect on the server. connect() on a datagram binds that socket with the peer and keeps wolfSSL from reading data from a different peer. To disconnect() on a datagram call connect() again by connecting to an invalid address, such as a null address or an address with the address family set to AF_UNSPEC (the error EAFNOSUPPORT will be harmlessly returned).
#
afelion

[Avatar]
2010-08-25 06:16:58 UTC
That makes a lot of sense. i have connect after recvfrom Do I need to close server socket, then bind and listen again for each new connection? Because if I using udp disconnect: struct sockaddr addr; addr.sa_family = AF_UNSPEC; connect(fd, &addr, 0); when client re send another data, it SSL_connect still return SOCKET_ERROR_E. I have more question: After writing on the socket, client close connection SSL_shutdown(ssl); close(SSL_get_fd(ssl)); SSL_free(ssl); and the server will be receive a data? because on server, I got SSL accept failed
#
afelion

[Avatar]
2010-08-25 06:30:50 UTC
I also test with your example: ./configure --enable-dtls ./make Run echoserver Run echoclient type GET -> return OK type break type quit Run echoclient again, got yassl error: SSL_connect failed
#
afelion

[Avatar]
2010-08-25 08:36:03 UTC
Sorry for my annoy, but I can not edit my previous post. Above error just because of SSL_shutdown send notify to server. I just remove it. One last question (hopefully): how the server identify clients connected to. For example: 1. Client 1 sends data -> Server accepts 2. Client 2 sends data -> Server accepts 3. Client 1 sends another data -> How server know this client and the client at step 1 are identical (same client). For example: client public key?
#
touskaProject Admin

[Avatar]
2010-08-25 22:16:24 UTC
After you type break on the echoclient you end the session with the server and should do a control-c. Trying to send a quit or the SSL_shutdown is a problem, I'll fix the echoclient for that case. The server can identify the client by the client ip address and client port.
#
afelion

[Avatar]
2010-08-26 02:35:24 UTC
"The server can identify the client by the client ip address and client port. " But connecting port is changed each time a client send data to the server, isn't it? The port is selected automatically by OS?
#
touskaProject Admin

[Avatar]
2010-08-26 16:50:26 UTC
Not if the client connect()s which is about the only way it can guarantee that it's only going to get UDP messages from the correct server during the handshake and data transmission. Do you know see why TLS is the better solution here?
#
afelion

[Avatar]
2010-09-09 10:14:39 UTC
As in #8, I said about implementation of my server/client: using select with non blocking socket, Both run ok, but if a client sends 5~10 packages in sequence (no delay) the server SSL_accept got error (-208), then can not listen to any clients. Do you have any suggestions?

#
Hi, I'd like to minimize the amount of RAM that is required by wolfSSL client -- hopefully to less than 28KB. Do you think this is possible? I am compiling in a non-standard environment, and am therefore using #defines to control how wolfSSL compiles. Here are the current #defines that I am using: #define NO_HC128 #define NO_DH #define NO_RABBIT #define NO_RC4 #define NO_DES3 #define NO_MD4 #define NO_DSA #define NO_PSK #define NO_CYASSL_SERVER #define SIZEOF_LONG_LONG 8 #define NO_FILESYSTEM #define NO_WRITEV Maybe there are other compile options that I should try? The big memory hog seems to be the SSL structure -- I cannot seem to get it below 40688 bytes in wolfSSL 1.5.4. I saw a suggestion in another form post of using dynamic buffers for the input / output streams. It seems like this wouldn't necessarily guarantee a smaller memory footprint (it would still be possible for wolfSSL to be attempting to receive/send 16K, in which case the same amount of memory would be required, right?). Maybe there is a way to make wolfSSL use the same input and output buffer? Any thoughts that you have will be greatly appreciated. Thank you, Eric
#
touskaProject Admin

[Avatar]
2010-07-19 17:35:33 UTC
Hi Eric, You're right nearly all of the memory is from the in/out buffers, 18,953 each. wolfSSL used to only use dynamic memory but at the request of users and for speedup static buffers were used instead. If you control both ends, or know for sure the max size of each record you will face, you can lower the buffer size by playing with #define BUFFER16K_LEN RECORD_HEADER_SZ + MAX_RECORD_SIZE + \ MAX_COMP_EXTRA + MAX_MTU + MAX_MSG_EXTRA in cyassl_int.h. Which reminds me, MAX_COMP_EXTRA is only used if compression is built in and MAX_MTU is really only used if sniffer mode is being used. That define needs to change to reflect that, you can remove both and save yourself 5k right there. 2 x (1,000 + 1,500). Now RECORD_HEADER_SZ and MAX_MSG_EXTRA (padding + MAC) should stay as they are but that's only 73 bytes. But you can lower MAX_RECORD_SIZE if you're not doing bulk data transfer, it's currently 16,384, the max raw data length of each SSL record. wolfSSL could be changed to only use one buffer for both input and output though it's not set up that way right now. Each buffer makes slightly different assumptions about itself and logic would need to be added to make sure each buffer is emptied before trying to use the other. For example, the client receives 10K from the server, but reads in 5k chunks and wishes to respond after reading the first chunk. Not easily possible with only one buffer. I think it might be best to abstract the input / output buffers. Make each a pointer that can point to a static buffer depending on build options, can share a buffer depending on build options, or even let the user control the buffer (not sure how much at this point). Any other ideas? What do you think? -Todd
#
elsevers

[Avatar]
2010-07-20 01:28:31 UTC
Hi Todd, Thank you for all of your insight! I like your idea of abstracting the input / output buffers and having build options to allow the user to have some control -- I think this would give wolfSSL a lot more portability to memory constrained systems if the user could somehow implement the input / output buffers in serial RAM. My max record size is 1K. However, I am not sure how large MAX_RECORD_SIZE needs to be to complete the SSL handshake (certificates and key exchange, etc). Do you have any thoughts on this? Do you think I can get by with MAX_RECORD_SIZE of 4K? Thanks, Eric
#
touskaProject Admin

[Avatar]
2010-07-20 20:18:43 UTC
Hi Eric, It depends on the servers you're connecting to and the certificates they're sending during the handshake. If the max data record size is 1k the only SSL record that can be bigger than that is the certificate record, which could be infintely large split into 16k SSL records. But typically, 1 - 3 certificates are sent with an average of say 1,250 bytes. So while 4k is probably fine I'd recommend 6k or even 8k to be safe. That still saves you 16k (8k x 2 buffers) + 5k from the other defines above for a saving of 21k. I'll post back after the buffer changes are made. Another idea occurred to me which is to have an option for small static buffers, configurable but defaulting to 1 or 2k, and then using dynamic memory when a larger record comes in for a certificate chain or a large data message. Does that work?
#
elsevers

[Avatar]
2010-07-21 01:16:17 UTC
Hi Todd, Great -- thanks the advice. I think 8k buffers will be sufficiently small for me. I like your latest idea best for the buffers. It seems that this will give the best of both worlds -- high speed for packets < 1 or 2k, and much smaller memory usage in the event of a large packet so long as the send and receive buffers do not simultaneously need to be large. This would certainly work well for my application. Cheers, Eric

2009-12-02 10:02:38 UTC
Does this http://www.mozilla.org/projects/securit … y-cbc.html or this http://cve.mitre.org/cgi-bin/cvename.cg … -2003-0078 apply to wolfSSL embedded SSL?
#
touskaProject Admin

[Avatar]
2009-12-03 00:37:41 UTC
The first attack isn't possible with wolfSSL since a general fatal alert is sent in this case instead of a more specific error that could potentially leak timing information. The second one doesn't affect wolfSSL since a MAC computation is done independent of padding errors, preventing the timing attack entirely.
#
sergii

[Avatar]
2009-12-03 09:56:23 UTC
Great! Thanks, Todd!

2009-11-12 20:17:01 UTC
Hi! We’ve been getting a number of questions about the high profile vulnerabilities in OpenSSL, GnuTLS, NSS and mod_ssl. This vulnerability is based on a potentially insecure SSL early feature that yaSSL chose to never support in the first place. As such, yaSSL was never insecure. More details on the issue can be found below: From CVE: http://cve.mitre.org/cgi-bin/cvename.cg … -2009-3555 “The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.”

2009-04-01 16:30:33 UTC
Hello, I noticed in AesSetKey() in aes.c that the key length is restricted to 16, 24 or 32 bytes.

I naively thought that an AES key length might be longer, like 256 or 4096. What have I misunderstood something about AES and/or the ctaocrypt API?
#
touskaProject Admin

[Avatar]
2009-04-01 19:54:10 UTC
The AES standard supports AES-128, AES-192, and AES-256. Those are key sizes in bits, which correspond to byte sizes of 16, 24, and 32 respectively.

Public key algorithms will use longer keys in the thousands of bits to represent huge numbers that are factors of other huge numbers. But block cipher key sizes are the actual length of the key. Even AES-128 has 2 ^ 128 different possible keys!

2008-12-04 09:46:40 UTC
I am using wolfssl to connect to a Tomcat server.
If I don't try to reuse the session id everything works fine.
When a session id is no longer valid wolfssl just negotiates a new session id, no problem.
However, when I restart tomcat in between two wolfssl calls (while trying to reuse the ID), the SSL_connect call hangs until the tomcat servers times it out (or in case of a non blocking implementation SSL_connect asks for more data which never arrives).

This does not happen with an apache server however other SSL implementations do not have the same issue with Tomcat.

Can you throw a few ideas about what can be the root cause for this and how can I go about debugging? I'd be happy to troubleshoot and "dive in the code" but will need a few pointers on where to start looking.

Yuval
#
touskaProject Admin

[Avatar]
2008-12-04 20:18:14 UTC
It sounds like the Tomcat server is trying to resume a session even though it no longer has context for it. Unless wolfSSL gets an error from the server it has no idea what's going on, eventually the socket call times it out. Not sure how the other implementations are catching this unless they're setting up their own timers to override the tcp ones. Are you sure the other ones are correctly sending the session ID in the client hello to try and resume?

Can you send me a wireshark trace of the wolfSSL failed connection attempt and also one of a different implementation successfully connecting after a hard reset while trying to resume? That may shed some more light on it for us.

Thanks.

2008-09-24 21:00:57 UTC
Does wolfSSL 0.9.9 support EV SSL certificates?

when i try a ssl_connect to loginnet.passport.com i get an ssl_failed error .... in beup (msn for nds).
troubleshooting this gave a error in ssl.c:

" /* get response */
while (ssl->options.serverState < neededState)
teller= ProcessReply(ssl);

if ( (ssl->error = teller) < 0) {
CYASSL_ERROR(ssl->error);
return SSL_FATAL_ERROR;}
"
So i think something goed wrong in cyassl_int.c:

int DoProcessReply(SSL* ssl)
which calls e.g.DoProcessReply
I expect the error to occure in there..

the CYASSL_ENTER("ProcessReply()"); and CYASSL_MSG( functions do not give any info on a nds...

I'm not a c++ guru so i have a problem to find what's wrong.
i traces the ssl traffic with wireshark...

you can download the file there:
http://filetrans.be.getronics.com/downl … mp;lang=en

(until 2008-10-04 )
Can someone please tell me what's going wrong?
Is it the EV SSL cert?
Is it a changed ca?
Is it a cipher which is not supported?
Please explain why you conclude this...

thx
Bas

#
touskaProject Admin

[Avatar]
2008-09-24 21:49:30 UTC
wolfSSL supports the certificate just fine. If you go the examples/client directory you can test this on Linux, Windows, or whatever by typing:

./client loginnet.passport.com 443

The server doesn't like the GET format but the SSL connect works and the encrypted response from the server is printed.

Did you change any other lines in wolfSSL? What error are you getting? You never say. wolfSSL isn't written in C++, it's all C.

From the packet capture it looks like you are shutting down the SSL session before you get a response from the server. The client hello is sent in packet 4 at time .3. The next SSL traffic is the client sending a close notify alert (shutdown) at time .8 packet 15. This is before the server even replies at time 1.1 packet 22.

Are you using non-blocking sockets and not restarting the call to SSL_connect?

#
bashendriks123

[Avatar]
2008-09-26 06:25:26 UTC
i tested the code with a wolfSSL 0.9.9 fresh download to see what i needed to change to get it to work.
First i compiled the cyassl 0.9.9 code with visual express 2008 and tested ./client loginnet.passport.com 443
When i changed the lines :
// if (SSL_CTX_load_verify_locations(ctx, caCert, 0) != SSL_SUCCESS)
// err_sys("can't load ca file");
in client.c it worked ok, otherwise i got an can't load ca file error message.

But when i compiled the code in beup (msn for nds) i had to change ctaocrypt\source\random.c because it doesn't know how to compile sleep:
// if (sz)
// sleep(1);

then i get indeed an "TLSv1 Record Layer: Alert (Level: Warning, Description: Close Notify)" because in ssl_connect i get an error in ssl.c on:
case CLIENT_HELLO_SENT :
neededState = ssl->options.resuming ? SERVER_FINISHED_COMPLETE :
SERVER_HELLODONE_COMPLETE;
/* get response */
while (ssl->options.serverState < neededState)
if ( (ssl->error = ProcessReply(ssl)) < 0) {
CYASSL_ERROR(ssl->error);
==> this line ==> return SSL_FATAL_ERROR;
}
ssl->options.connectState = FIRST_REPLY_DONE;
CYASSL_MSG("connect state: FIRST_REPLY_DONE");

and so the beup program shutsdown the ssl connection.
In cyassl_int.c the int ProcessReply(SSL* ssl)
function/procedure is defined which calls in the same file:
int DoProcessReply(SSL* ssl)
somewhere in these two someting goes wrong....

The ssl connection is being build up from msn.cpp (part of beup) in authenticate:

"static void authenticate() {
int size;
int response, passSock;
sockaddr_in addr;
char *str;
int ip;

debug->append(strRep("MsnAuthTicket"));
sscanf(recBuf, "USR %*s TWN S %s\r\n", buffer3);

passSock = socket(PF_INET, SOCK_STREAM, 0);
addr.sin_family = AF_INET;
addr.sin_port = htons(443);

ip = (strstr(user.account, "msn.com")) ? Msn_IP : Passport_IP;

addr.sin_addr.s_addr = ip;
connect(passSock, (sockaddr*)&addr, sizeof(addr));

urlEncode(user.account, buffer);
urlEncode(user.password, buffer2);

SSL_METHOD* method = 0;
SSL_CTX* ctx = 0;
SSL* ssl = 0;

method = TLSv1_client_method();
ctx = SSL_CTX_new(method);

SSL_CTX_load_verify_locations(ctx, SSL_Certificate, 0);

ssl = SSL_new(ctx);
SSL_set_fd(ssl, passSock);

debug->append(strRep("MsnPassConnected"));

==> error occure here ==> if (SSL_connect(ssl) != SSL_SUCCESS) {
debug->append(strRep("MsnSSLConnectFailed"), ErrColor);
notState = State_AuthFailed;
if (loginTab->chkAutoerror.selected) loginTab->connect();
} else {
char redir[25];
strcpy(redir, "/login2.srf");
debug->append(strRep("MsnSSLConnected"));
while (true) {
size = snprintf(recBuf, RecBufSize, Passport_GET, redir, buffer, buffer2, buffer3);
if (SSL_write(ssl, recBuf, size) != size) {
debug->append(strRep("MsnSSLSendFailed"), ErrColor);
notState = State_AuthFailed;
break;
}
recBuf[SSL_read(ssl, recBuf, RecBufSize)] = 0;

response = 0;
sscanf(recBuf, "%*s %d", &response);
if (response == 302) {
str = strstr(recBuf, "Location:");

debug->append("Got a 302 transfer. Support for this is still buggy.");
debug->append("If authentication fails, please report this location to the boards:");
debug->append(str);

notState = State_AuthFailed;
break;
} else break;
}
}

if (notState != State_AuthFailed) {
if (response == 200) {
str = strstr(recBuf, "from-PP");
sscanf(str, "from-PP='%s", buffer3);
*index(buffer3, '\'') = 0;
notState = State_Authenticated;
debug->append(strRep("MsnAuth200"));
} else if (response == 401) {
debug->append(strRep("MsnAuth401"), ErrColor);
notState = State_AuthFailed;
}
}
Print("<<%s", recBuf);

==> shutdown ssl occures there==> SSL_shutdown(ssl);
SSL_free(ssl);
SSL_CTX_free(ctx);
close(passSock);

recBuf[0] = 0;
recSize = 0;
bufferWaiting = false;
}

"

Can you please tell me:
-does the change in random.c have an effect on the alert.notify and if yes any idea how to fix this?
-any idea why the ssl_connect failes?, does it use the correct statements to build up a ssl connection?

With Kind regards,
Bas

#
touskaProject Admin

[Avatar]
2008-09-26 18:12:19 UTC
You shouldn't have to comment out the lines in client.c, that means you're probably running ./client from the wrong directory.

Can you use a different call then sleep() to get the same effect, it probably isn't causing the problem though?

You still don't say what the actual error is. You can either look directly at the value of ssl->error or you need to call SSL_get_error() to get it. Without knowing the actual error it's hard to say what's going on. The code steps are in the right order, though no error checking is being done so something else could be going wrong too.

#
bashendriks123

[Avatar]
2008-09-27 08:29:14 UTC
Well my c knowlegde is not so good, so finding another sleep functon is not so easy but i will try. (if you have a sleep function for me would be great).
I'm compiling on windows and i already have seen some error reflecting on functions which apperently exist in linux code.

When i use error checking then the error of ssl_get_error is a 2 which should be a ssl_read error.
No other errors appear so ssl_connect gives the error.

i will try to read the ssl-> error and getback on that too.

============
char * itoa(int n, char *buff, int radix)
// convert a positive integer n to char *buff
// for instant, this function work with radix <= 10;
// a little change to run with radix > 10
{
int q, r;
int i = 0;
char tmp[33]; // for radix = 2 and 32 bits computer
do{
q = int(n / radix);
r = n % radix;
n = q;
tmp[i++] = 48 + r;
}while(q > 0);
int j;
for(j = 0; j < i; j++){
buff[j] = tmp[i - j - 1];
}
buff[j] = NULL;
return buff;
}

static void authenticate() {
int size, status, erro, ret, ret14;
int response, passSock;
sockaddr_in addr;
char *str;
int ip;
char erro_buf[5];
char erro_buf7[100];
char erro_buf13[100];
char erro_buf14[100];

/* char msg[] = "hello cyassl!";
char reply[1024];
int input;
int msgSz = sizeof(msg);
*/

status = 0;

debug->append(strRep("MsnAuthTicket"));
sscanf(recBuf, "USR %*s TWN S %s\r\n", buffer3);

passSock = socket(PF_INET, SOCK_STREAM, 0);
addr.sin_family = AF_INET;
addr.sin_port = htons(443);

ip = (strstr(user.account, "msn.com")) ? Msn_IP : Passport_IP;

addr.sin_addr.s_addr = ip;
connect(passSock, (sockaddr*)&addr, sizeof(addr));

urlEncode(user.account, buffer);
urlEncode(user.password, buffer2);

SSL_METHOD* method = 0;
SSL_CTX* ctx = 0;
SSL* ssl = 0;

method = TLSv1_client_method();
ctx = SSL_CTX_new(method);

// SSL_CTX_load_verify_locations(ctx, SSL_Certificate, 0);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

ssl = SSL_new(ctx);

if (ssl == NULL) {
debug->append("Could not allocate 'ssl' with SSL_new()\n");
};

//SSL_set_fd - connect the SSL object with a file descriptor
status=SSL_set_fd(ssl, passSock);
if (status==0) {debug->append("Could not connect ssl object with file descriptor");}
else
{debug->append("ssl object connected with file descriptor");};

debug->append("passSock: ");
debug->append(itoa ( passSock, erro_buf7, 10 ));

debug->append(strRep("MsnPassConnected"));

//SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
status=SSL_connect(ssl);
ret=status;
debug->append("status (1-10) : ");
debug->append(itoa ( status, erro_buf13, 10 ), ErrColor);

// if (status != SSL_SUCCESS) {
// erro= SSL_get_error (ssl, status);

erro= SSL_get_error(ssl, 0);
debug->append( itoa ( erro, erro_buf, 10 ), ErrColor);

if (erro == 2)
debug->append("... client would read block");
else
if (erro == 3)
debug->append("... client would write block");
else
debug->append("... client neither read nor write");

if (SSL_connect(ssl) != SSL_SUCCESS) {
debug->append(strRep("MsnSSLConnectFailed"), ErrColor);
notState = State_AuthFailed;
if (loginTab->chkAutoerror.selected) loginTab->connect();
} else {
char redir[25];
strcpy(redir, "/login2.srf");
debug->append(strRep("MsnSSLConnected"));
while (true) {
size = snprintf(recBuf, RecBufSize, Passport_GET, redir, buffer, buffer2, buffer3);
if (SSL_write(ssl, recBuf, size) != size) {
debug->append(strRep("MsnSSLSendFailed"), ErrColor);
notState = State_AuthFailed;
break;
}
recBuf[SSL_read(ssl, recBuf, RecBufSize)] = 0;

response = 0;
sscanf(recBuf, "%*s %d", &response);
if (response == 302) {
str = strstr(recBuf, "Location:");

debug->append("Got a 302 transfer. Support for this is still buggy.");
debug->append("If authentication fails, please report this location to the boards:");
debug->append(str);

notState = State_AuthFailed;
break;
} else break;
}
}

if (notState != State_AuthFailed) {
if (response == 200) {
str = strstr(recBuf, "from-PP");
sscanf(str, "from-PP='%s", buffer3);
*index(buffer3, '\'') = 0;
notState = State_Authenticated;
debug->append(strRep("MsnAuth200"));
} else if (response == 401) {
debug->append(strRep("MsnAuth401"), ErrColor);
notState = State_AuthFailed;
}
}
Print("<<%s", recBuf);

SSL_shutdown(ssl);
SSL_free(ssl);
SSL_CTX_free(ctx);
close(passSock);

recBuf[0] = 0;
recSize = 0;
bufferWaiting = false;
}
==================
#
touskaProject Admin

[Avatar]
2008-09-29 05:12:54 UTC
The error you're getting from SSL_connect via SSL_get_error is SSL_ERROR_WANT_READ. This is not just an SSL_read error, this can happen on connect too, like you're getting, because connect reads and writes SSL records. You're getting the error because your socket is non-blocking and the data from the server hasn't arrived yet. Just like the packet capture showed. You need to call SSL_connect again once the data is there. From the man page:

If the underlying BIO is non-blocking, SSL_connect() will also return when the underlying BIO could not satisfy the needs of SSL_connect() to continue the handshake, indicating the problem by the return value -1. In this case a call to SSL_get_error() with the return value of SSL_connect() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_connect(). The action depends on the underlying BIO. When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition.

The whole page is here: http://openssl.org/docs/ssl/SSL_connect.html

As for Windows code vs. Unix code, if you're compiling for Windows then your compiler needs to define _WIN32, if it's broken (and doesn't) then it will try and compile the Unix code which will obviously not work (like sleep). Which compiler, version, target are you using?
#
bashendriks123

[Avatar]
2008-09-29 07:31:08 UTC
Tod,

thx!!
The ssl connection is made!

I just put the ssl_connect in a while loop.

"//SSL_set_fd - connect the SSL object with a file descriptor
status=SSL_set_fd(ssl, passSock);
if (status==0) {debug->append("Could not connect ssl object with file descriptor");}
else
{debug->append("ssl object connected with file descriptor");};

debug->append("passSock: ");
debug->append(itoa ( passSock, erro_buf7, 10 ));

debug->append(strRep("MsnPassConnected"));

//SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
status=SSL_connect(ssl);
ret=status;
debug->append("status (1-10) : ");
debug->append(itoa ( status, erro_buf13, 10 ), ErrColor);

// if (status != SSL_SUCCESS) {
// erro= SSL_get_error (ssl, status);

erro= SSL_get_error(ssl, 0);
debug->append( itoa ( erro, erro_buf, 10 ), ErrColor);

if (erro == 2)
debug->append("... client would read block");
else
if (erro == 3)
debug->append("... client would write block");
else
debug->append("... client neither read nor write");

while (status != SSL_SUCCESS )
// && (erro == 2 || erro == 3)

{
debug->append("in de while loop");
//SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
status=SSL_connect(ssl);

erro= SSL_get_error(ssl, 0);
debug->append( itoa ( erro, erro_buf, 10 ), ErrColor);
};

if (SSL_connect(ssl) != SSL_SUCCESS) {
debug->append(strRep("MsnSSLConnectFailed"), ErrColor);
notState = State_AuthFailed;
if (loginTab->chkAutoerror.selected) loginTab->connect();
} else {"

"Which compiler, version, target are you using? "
I' working on winxp sp3, compiling with devkitpro 1.4.7 for nintendo DS so arm 9 (and arm 7) processor.

#
bashendriks123

[Avatar]
2008-09-30 05:58:24 UTC
i'm still not sure if the ssl connection stays ok...
I still see a tls alert message
can anyone see if this is ok or not?

http://filetrans.be.getronics.com/downl … mp;lang=en

with kind regards,
bas hendriks

#
touskaProject Admin

[Avatar]
2008-09-30 20:48:04 UTC
TLS alerts are a normal part of SSL shutdowns, so the question is, did you shutdown the connection? If not, what error did you get? Are you restarting SSL_read() to get all the data you want with non-blocking sockets?

How do i troubleshoot an ssl connection when it's using cyassl?
I cannot use ssl_get_error
I cannot use SSL_set_connect_state
i cannot use BIO options
.....
What can i use and can you please give me an example.
I'm using c++

And is there maybe a way to add extra options to wolfssl?

With kind regards,
Bas Hendriks
#
touskaProject Admin

[Avatar]
2008-09-11 19:09:23 UTC
There are several ways you can troubleshoot a wolfSSL connection; print out error codes, capture SSL packets, connect with an SSL program you know better to see their error code...

Why can't you use SSL_get_error()?

If you wan't C++ and more OpenSSL compatibility you should try yaSSL. SSL_set_connect_state() is there. Otherwise you can manually set your method object on creation with one the functions like TLSv1_client_method().

What BIO options do you need for an SSL connection? If it's non-blocking you can set that on the socket directly.

There are plenty of examples in the examples directory showing clients, servers, non-blocking, testing error-codes, and the like. Please take a look at them.

Feel free to add options to wolfSSL or you can make a case why an option should be in an embedded ssl product. That is, something that can't easily be done another way and provides desired functionality. We're happy to add options but we're also concerned with keeping the product very small, so there's always a trade off.

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.

2007-12-13 06:19:18 UTC
hello:
I had make client certificate , server certificate and ca. my os is linux.
How can I do verify the server certificate use the wolfssl? Could you give me an example?
thanks.

2008-01-07 21:45:23 UTC
Hi,

Sorry for the delay, I missed this post.

The best example is in examples/client/client.c. The call to SSL_CTX_load_verify_locations() sets the CA you wish to verify the server with. An error code from SSL_connect() may indicate a verification error, e.g., out of date or invalid signature.

Hope this helps,
Todd

1.
      charlesxu

      [Avatar]
      2007-02-28 02:30:47 UTC
      Hi,

      Does wolfSSL embedded SSL support the optional authenticating the client to the server? Is there any plan to implement it soon if it doesn't.

      Thanks
      Charles
   2.
      touskaProject Admin

      [Avatar]
      2007-03-01 23:51:04 UTC
      wolfSSL doesn't support client certificate authentication. The basic reason is to keep the size small, yaSSL does support this feature. The other reason is that it's usually much simpler to just do a challenge/response once the handshake is complete. If it's important I can probably add the basics of the feature as a build option.

      Regards,
      Todd
   3.
      charlesxu

      [Avatar]
      2007-03-02 17:58:56 UTC
      I am involved in a project of using security connection for client provisioning. It's crucial that the server be able to auhenticate the client. Other features required are DN verification and chained certificates validation.

      Thanks
      Charles
   4.
      panpipi

      [Avatar]
      2007-03-07 19:12:47 UTC
      Coincidently I also involved in a project that needs server to authenticate clients and requires DN verification and chained certificate validation.

      Peter
   5.
      moises_phoebus

      [Avatar]
      2007-10-18 12:54:20 UTC
      It is important to my project... can you add this feature as a build option like you said?
   6.
      touskaProject Admin

      [Avatar]
      2007-10-23 18:43:23 UTC
      OK, after I finish OpenVPN and stunnel support I'll add client certificate authentication as my next free project for wolfSSL.
   7.
      touskaProject Admin

      [Avatar]
      2007-10-29 23:27:25 UTC
      OK, I've checked in initial client authentication support for wolfSSL. It's available from CVS. Feel free to test and let me know what you think.