I want to know the functions which establish the SSL connection from windows.. I am writing a code to know whether the SMTP uses SSL of TLS ..i am able to find get TLS because encryption happens after handshake... i want to know about SSl .. please help me.
Thank you in advance
OpenSSL is the most common library used for SSL.
Related
In a server application, once a connection has been established I can grab the client certificate from the SSL * I have. Is there a way to find out which CA I used to validate that certificate?
You can use the SSL_get0_verified_chain() function for this purpose. See the documentation here:
https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_verified_chain.html
Note that this function was first introduced in OpenSSL 1.1.0, so this won't work in OpenSSL 1.0.2.
This post seems on point:
Find client certificate information from server in OpenSSL
Since SSL_get_peer_certificate returns an X509 cert, I would expect that the cert chain would be included (you couldn't handle a CRL properly without it, I'd think)?
I am trying to figure out how to tell Boost Beast to use a client authentication certificate during the SSL handshake.
I have looked at the Boost Beast documentation, but have been unable to find any hint on client side certificates. The examples also do not cover this case.
we have put our gsoap stubs c++ into a custom dynamic library, linked and built it against our main program.
When i use a https call i get ERROR_SYSCALL from openssl and see that it fails in the SSL_Connect.
The exact error is:
sk_sort:0xb6cc1680
SOAP 1.2 fault SOAP-ENV:Receiver [no subcode]
"SSL_ERROR_SYSCALL
Error observed by underlying SSL/TLS BIO: Connection reset by peer"
Detail: SSL_connect error in tcp_connect()
If i use the same code directly in our main program it works without any problem...
What am I missing ? our custom library is dynamic and linking also openssl dynamically...
With kind regards
Not exactly problem with custom library but with latest GSOAP.
Gsoap added SSL_set_tlsext_host_name to use SNI with TLS. If you are using IP based server with default SSL certificate e.g. no SNI then all calls will fail with ERROR_SYSCALL
So we solved it like this for now:
SSL_set_tlsext_host_name(soap->ssl, host) - WHICH causes ERROR SYSCALL because we are using IP and not host name. And server drops the link as hostname is ip and not a valid name. As we need to use IP instead of hostname and gsoap does not use any flag for this, we commented out the part in stdsoap2.cpp
We just searched SSL_set_tlsext_host_name in stdsoap2.cpp and commented out.
Probably Gsoap should have a flag for this ?
Hi I want to make a basic ssl connection without using certificate with my client and server using c++ and openssl . I have been trying with SSL_connect and SSL_accept with no luck getting the handshake with the BIO object first. Should I even bother with any SSL functions if I am not using any certificates? I have been researching around and found BIO wrapper for ssl and I am wondering is that is the way to go.
I'm attempting to write a simple HTTP/HTTPS proxy using Boost ASIO. HTTP is working fine, but I'm having some issues with HTTPS. For the record this is a local proxy. Anyway so here is an example of how a transaction works with my setup.
Browser asks for Google.com
I lie to the browser and tell it to go to 127.0.0.1:443
Browser socket connects to my local server on 443I attempt to read the headers so I can do a real host lookup and open a second upstream socket so I can simply forward out the requests.
This is where things fail immediately. When I try to print out the headers of the incoming socket, it appears that they are already encrypted by the browser making the request. I thought at first that perhaps the jumbled console output was just that the headers were compressed, but after some thorough testing this is not the case.
So I'm wondering if anyone can point me in the right direction, perhaps to some reading material where I can better understand what is happening here. Why are the headers immediately encrypted before the connection to the "server" (my proxy) even completes and has a chance to communicate with the client? Is it a temp key? Do I need to ignore the initial headers and send some command back telling the client what temporary key to use or not to compress/encrypt at all? Thanks so much in advance for any help, I've been stuck on this for a while.
HTTPS passes all HTTP traffic, headers and all, over a secure SSL connection. This is by design to prevent exactly what you're trying to do which is essentially a man-in-the-middle attack. In order to succeed, you'll have to come up with a way to defeat SSL security.
One way to do this is to provide an SSL certificate that the browser will accept. There are a couple common reasons the browser complains about a certificate: (1) the certificate is not signed by an authority that the browser trusts and (2) the certificate common name (CN) does not match the URL host.
As long as you control the browser environment then (1) is easily fixed by creating your own certificate authority (CA) and installing its certificate as trusted in your operating system and/or browser. Then in your proxy you supply a certificate signed by your CA. You're basically telling the browser that it's okay to trust certificates that your proxy provides.
(2) will be more difficult because you have to supply the certificate with the correct CN before you can read the HTTP headers to determine the host the browser was trying to reach. Furthermore, unless you already know the hosts that might be requested you will have to generate (and sign) a matching certificate dynamically. Perhaps you could use a pool of IP addresses for your proxy and coordinate with your spoofing DNS service so that you know which certificate should be presented on which connection.
Generally HTTPS proxies are not a good idea. I would discourage it because you'll really be working against the grain of browser security.
I liked this book as a SSL/TLS reference. You can use a tool like OpenSSL to create and sign your own certificates.