Topic: wolfSSL_read() Capabilities
Questions:
1. Can wolfSSL handle unencrypted traffic?
2. Can wolfSSL handle HTTP/1.1 CONNECT requests for SSL tunnelling?
3. If 'yes' to either of the above, is there any documentation for reference?
p
You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → wolfSSL → wolfSSL_read() Capabilities
Questions:
1. Can wolfSSL handle unencrypted traffic?
2. Can wolfSSL handle HTTP/1.1 CONNECT requests for SSL tunnelling?
3. If 'yes' to either of the above, is there any documentation for reference?
p
So I wrote an HTTP proxy that sends a 200 OK back to browser after receiving a CONNECT request and connecting to the host, after this point I let wolfSSL take over as server but the browser spits up HTTP 107 SSL error - is it a certificate issue or have I got the protocol wrong?
As for unencrypted traffic, when I let it go through wolfSSL I get a hang and clicking abandon crashes VC2010, otherwise a break point is triggered with an invalid null pointer somewhere in the library code. Wouldn't mind a simple yes/no from someone who knows on this one.
wolfSSL handles SSL/TLS encrypted traffic only.
wolfSSL doesn't "know" protocols that sit on top SSL/TLS. Though wolfSSL can certainly be used to implement them.
Shouldn't the proxy send back "HTTP/1.0 200 Connection established" to a CONNECT request after doing a TCP connect to the server? Also, CONNECT is an SSL tunnel meaning the browser is the SSL client and the web server is the SSL server. The proxy just passes the tunneled info back and forth. How is wolfSSL fitting into this?
How do you pass unencrypted traffic to wolfSSL? If you issue a wolfSSL_accept() it should return with an error.
Hi todd,
Thanks for the heads up on unencrypted traffic.
Yes, precisely the proxy sends back "HTTP/1.0 200 Connection established" after making the connection, I assume the client then sends "GET HTTPS://...." which I have wolfSSL handle in server mode at which point the browser produces said error.
The reason for this is to make a "bridging" proxy, to be able to monitor my SSL traffic in cleartext at a local HTTP proxy level.
I tried wolfSSL_read() after a socket had been accept()'ed the usual way, at the time my proxy was opening a new thread for each request from browser, so the invalid nullptr was probably because the object was on a different thread.
No, after the client gets a "Connection established" it starts a SSL/TLS handshake. After that is complete it will issue a GET or whatever it wants.
The easiest way to monitor this is to put Wireshark between the browser and proxy. Make sure what you think is happening is happening.
The browser is not going to like having wolfSSL pretend to be the server. The hostname of the certificate won't match and it won't be signed by a trusted authority. This is not a simple task. Read up on the relevant RFCs for HTTP,SSL, proxies.
So at the SSL handshake point it is not unreasonable to use wolfSSL for that abstraction. Is the failure likely to be a certificate issue? I would have expected the browser to prompt a warning of an untrusted certificate if wolfSSL succeeded in completing the handshake?
Hard to say. Wireshark will provide more info about what's happening at the handshake level and if you're actually getting that far. Could be a protocol version problem.
Yes. wolfSSL is good to use for the SSL handshake. See the echoserver example for maximum browser compatibility.
Thanks for the insights into SSL and your help with the embedded SSL library. I'll take the advice on sniffing with Wireshark.
wolfSSL - Embedded SSL Library → wolfSSL → wolfSSL_read() Capabilities
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.029 seconds (88% PHP - 12% DB) with 12 queries