The code for SSL_do_handshake can be found at OpenSSL/ssl/ssl_lib.c.
The SSL_do_handshake function will wait for a TLS handshake to take place.
I am not able to understand the logic for the implementation. If my understanding is correct, the TLS handshake consists of a few steps before a symmetric key is generated. Where can I find the various steps in code (sending client hello, etc) for the implementation of the SSL_do_handshake() function. Are these steps in different parts of the OpenSSL library. If so, how are they tracked/called in the do_handshake function ?
Broader context:
Software like apache/nginx uses OpenSSL in their code. I would like to replace the SSL_do_handshake() function used in the apache/nginx code with a modified handshake. For this I need to understand the logic for the implementation in OpenSSL. Note, that I am looking to replace the API call with my modified API call. I do not want to make changes to openssl and then recompile and use the modified OpenSSL library. The modified_handshake API should be able to replace the symmetric key generated at the end of the handshake with a user generated key.
Related
i'm trying to send post request to daemon which is SSL applied. i want to pass the SSL verification and encrypt with SSL at the same time and here is what i found :
verify=false
but i can't find simillar one in twisted agent.request.
Control TLS behavior using the contextFactory argument to twisted.web.client.Agent.__init__.
The value for this parameter should provide twisted.web.iweb.IPolicyForHTTPS. This interface defines a method (creatorForNetloc) which is used to set up the TLS connection.
Twisted includes one distinct implementation of this interface which implements a policy like that used by most modern web browsers.
You can create your own implementation which does something else, such as disregard certificate validation errors - even on a per-host basis - or does things like adds custom trust roots so you can still verify the certificate without requiring it be issued by a certificate authority.
twisted.internet.ssl.optionsForClientTLS is useful for implementing some behaviors in creatorForNetloc - however it does not support completely ignoring all validation errors. For that, you might benefit from using twisted.internet.ssl.ClientTLSOptions which accepts an arbitrary OpenSSL.SSL.Context instance that controls most of its behavior.
OpenSSL.SSL.Context lets you control approximately every feature of OpenSSL that it is possible to control when using TLS with Twisted - including ignoring validation errors, if that's what you really need.
The most straightforward way to do that is to use Context.set_verify with a suitably defined function.
I am learning TLS mutual authentication using Openssl.
During the TLS handshake process, I want to run the code I wrote separately for the two processes below.
Part of signing with your private key
Verification part of the certificate received from the other party
Note that I try to do this in a trustzone or a separate secure area.
I'm looking at the openssl content, and I'm not sure which APIs can handle these things.
I do not know how to approach this now.
If anyone knows about this, please reply.
Looks like you have a requirement for using TPM for Private Key. You should take a look at https://github.com/ThomasHabets/openssl-tpm-engine. This could be of some help. Apart from that, there is no known callbacks for Private Key Signing. But, as Steffen Ullrich correctly mentions, the SSL_CTX_set_verify function can help you to add your own logic for validating the certificate received from Peer.
From what I know a certificate signing process involves invoking "openssl ca", input CA and a certificate signing request. The process then outputs a certificate signed by CA.
How is it possible to setup "openssl ca" and "CA key" in a remote server, then send to them a "signing request" from localhost and get back "signed cert"?
[The following is added after receiving comments that the question was uncleared.]
Are there any open-source certificate signing server/client tools (a google search showed me nothing, maybe I lacked the right keyword?)? I guess the solution involves a server/client wrapper around openssl that additionally do (secure) file transfering and simple handshakes to start/end signing transactions. First I tended to not implement the tool myself as I am not a security expert. Second to my guess such a tool must already exists and I should not reinvent it.
I've found the communication protocol that supports remote certificate signing: https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment
a reference implementation: https://letsencrypt.org/getting-started/
and the backend server behind it: https://github.com/letsencrypt/boulder/
I hope it is the solution I looked for.
Is it possible to have a cut down implementation of TLS , where we just
presume the server we are connecting to is trusted - after the server sends its
certificate, can we bypass verification of this and do away with any further
processing , and get right into standard http ? Is using public key encryption
something that is absolutely necessary , or can it be skipped ?
Rewording my question.
Is it possible to write a tls engine by skipping the need to use RSA public key
code ?,
or
Can a client notify the server during the handshake that it just requires the severs certificate
info, company name, expiry dates and requests the secret cipher key to be sent in plain text.
Skipping something in a protocol I don't fully understand is generally a bad idea.
Only steps marked as optional in the RFC can be safely skipped.
Therefore if you don't plan to use client-side certificate based authentication you can skip it.
However what you can do however is limit the number of variations in your implementation. This means support only one TLS version (e.g. TLS 1.2) and support only one dedicated cipher suite.
Anyway the pitfalls when implementing TLS are so numerous that I recommend you to use an existing implementation (e.g. implementing in a way that does not allow side channel attacks is not that simple and requires knowledge on that topic). There are other implementations beside OpenSSL with a much smaller footprint.
BTW: If you can presume the connection is trusted you don't need TLS. If you need TLS it should be a secure.
where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing
The point of verification is less to find out if the server is trusted, but more that you are actually talking to the server you expect to. If you omit this step you are open to man-in-the-middle attacks.
But, TLS is a very flexible protocol and there are actually ways to use anonymous authentication or a shared secret with TLS and thus skip usage of certificates. Of course in this case you would need to have some other way to validate the server, because otherwise you would be still open to man-in-the-middle-attacks. And because this use case is mostly not relevant for the common usage on the internet it is usually not implemented inside the browsers.
For certificate authentication, when a certificate is being sent to the remote side is it possible to attach an extra string, such that the certificate will be displayed along with the special string?
The idea proposed for my project is: A creates a random string, A sends the random string along with its certificate to B, A sends the random string via different media to B, finally B sees the certificate and also compares the string to authenticate A.
Anyway, the fundamental problem is: A and B do not share common in their certificate verification path, and they still want mutual authentication.
Although the proposed one is implementable, I don't know how to reduce the amount of work by leveraging available OpenSSL API's more efficiently. If I end up doing encryption and socket level send/recv by myself, that will be nightmare. Or is there any other tools can achieve that? Thanks a lot.
If the certificates can not be validated and trusted for whatever reason, it makes sense not to use them at all then. TLS supports alternative authentication schemes including OpenPGP, pre-shared keys and one-time passwords. OpenSSL supports pre-shared keys, if memory serves, and there exist alternative libraries depending on the platform.