I need a snippet of code for a program i am writing with Boost Asio SSL.
I have a system of two clients, that connect with each other. I require them to do a mutual authentication, so, that at the end of the handshake() command, both clients can be certain that the other client has the private key to the certificate they supplied.
Both clients have a context object, lets call them ctx1and ctx2 and each client has a public certificate and a private key.
Is it possible to set up the context objects so, that when i call socket.handshake() the clients will do a two-way authentication. If not, what would be the correct way to go about to achieve my goal ?
It looks like boost just uses the OpenSSL interface.
I don't know boost much but I've implemented lots of OpenSSL internals for Perl and came to the following conclusions after reading the relevant parts of the boost source code:
To have mutual authentication with OpenSSL you have to use SSL_VERIFY_PEER on the client side and SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the server side. If you use only SSL_VERIFY_PEER on the server side it will only send the certificate request to the client, but silently accept if the client sends no certificate back.
With boost this would probably be:
ctx.set_verify_mode(ssl::verify_peer); // client side
ctx.set_verify_mode(ssl::verify_peer|ssl::verify_fail_if_no_peer_cert); // server side
If you set verify_mode this way it will verify the certificates against the configured trusted CAs (set with ctx.load_verify_file or ctx.load_verify_path).
If you have full control over the CA which signed the certificates (i.e. its your own CA) it might be enough for you to accept any certificates signed by this CA. But if you use a CA which also signed certificates you don't want to accept, like typically the case with public CAs, you also need to verify the contents of the certificate. Details how to do this depends on your protocol, but for the usual internet protocols like HTTP or SMTP this involves checking commonName and/or subjectAltNames of the certificate. Details like wildcard handling vary between the protocols.
Boost provides rfc2818_verification to help you with HTTP-style validation, although from reading the code I think the implementation is slightly wrong (multiple wildcards accepted, IDN wildcards allowed - see RFC6125 for requirements).
I don't know of any standards for verifying client certificates. Often just any certificate signed by a specific (private) CA will be accepted. Other times certificates from a public CA matching a specific e-mail pattern. It looks like boost does not help you much in this case, so you probably have to get OpenSSL SSL* handle with sock.native_handle() and then use OpenSSL functions to extract certificate (SSL_get_peer_certificate) and to check the contents of the certificate (various X509_* functions).
At least if public CAs are involved you should also check the revocation status of the certificates. It looks like boost does not provide a direct interface to CRL (certificate revocation list) so you have to use ctx.native_handle() with the appropriate OpenSSL functions (X509_STORE_add_crl etc). Using OCSP (online status revocation protocol) is way more complex and relevant OpenSSL functions are mostly undocumented, which means you have to read the OpenSSL source code to use them :(
One cant force other side to authenticate against you, it is up to protocol, Ieach side autenticate only against other side. Just follow manuals as http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/ssl.html
ssl::context ctx(ssl::context::sslv23);
ctx.set_verify_mode(ssl::verify_peer);
ctx.load_verify_file("ca.pem");
Related
I have a problem.
I am using openssl for validate my cert - x509_verify_cert(). But this function doesn't use ocsp. So it can be a problem if there is no crl.
In openssl errors i found this define - x509_err_ocsp_verify_needed, but i don't understand how it uses.
It seems that may be exists some kind of callback for my connecting to ocsp server function or something like that.
Also i found it which i can use, as i understand, for my own validate function, but i want only ocsp check.
So my question is: is it possible ask openssl use ocsp for validation and how?
It is possible :
openssl ocsp -issuer certchain.pem -cert cert.pem -text -url <the ocsp responder URL>
Some links to articles with more details:
https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html
https://akshayranganath.github.io/OCSP-Validation-With-Openssl/
OpenSSL API does not provide a single API to do OCSP validation. The OpenSSL API provides the primitives so that you can implement your own validation. There are details you need to fill to the implementation which may depend on your situation you are trying to solve.
I would suggest that you get to know the openssl ocsp command as a basis of your understanding. Reading the links from Sanjeev's answer gives you examples of using this command as well.
To implement OCSP validation you will need to:
Extract server and issuer certificates from somewhere (SSL connection most likely)
Extract the OCSP server list from the server certificate
Generate a OCSP request using the server and issuer certificates
Send the request to the OCSP server and get a response back
Optionally validate the response
Extract the certificate status
Optionally you can also cache the result with the response update date range so that you can shortcut the above procedure if you see the certificate again.
You can also group a bunch of server certificates to the same OCSP server into a single request as well.
Of note is that the OCSP server link may not be HTTP and you may need to support whatever link type the certificate may have. For example in windows AD enterprise setups, the server OCSP may only have LDAP OCSP server links.
You may also like to see my answer to a question where I go into code examples of OCSP request and response handling.
UPDATE:
If you want to check the whole chain, you will have to do the above one certificate at a time (although the certificates operations can be overlapped). As far as I know, there is no way to check a whole chain at once. Also, you may find that a lot of intermediate certificates don't provide OCSP links anyway so there is no way to check. If you need to do this then it would be a good idea to cache the results as you will come across the same intermediate certificates all the time. In fact you could schedule to do this ahead of time for "known" intermediate certificates that you come across all this time.
You also keep pointing to "x509_verify_cert" check I quote:
Applications rarely call this function directly but it is used by
OpenSSL internally for certificate validation, in both the S/MIME and
SSL/TLS code.
So you shouldn't be calling this yourself anyway.
It seems that may be exists some kind of callback for my connecting to ocsp server function or something like that.
X509_STORE_CTX_set_verify_cb - used to set a callback to do your own custom verification - used a lot in server SSL setups
X509_STORE_CTX_set_ex_data - used to add custom argument values used by the callback
X509_VERIFY_PARAM_set_flags - used to setup flags (e.g. X509_V_FLAG_CRL_CHECK or X509_V_FLAG_CRL_CHECK_ALL)
In openssl errors i found this define - x509_err_ocsp_verify_needed
X509_V_ERR_OCSP_VERIFY_NEEDED is defined and never used in the openssl codebase. It is meant to returned from a verify callback function that the user provides (i.e. X509_STORE_CTX_set_verify_cb) to indicate that verification should fail with that error. What you do with that information is up to you. If you supply a callback and return that error from a openssl SSL connection that the SSL connection will terminate.
Also of note, if you do add a custom verification callback that does do full OCSP checking, it will slow down the SSL connection setup a lot. This is why most browsers don't do this by default as it slows down the user experience to much.
In https protocol a per-secrect key is generated by client and is sent to server . And for thereon symmetric encryption takes place .My question is if this is the case how a message digest is considered as signed by server .
Or the digital signature comes to play only in establishing https connection ?.
Does it apply only to public keys ?.
You skipped the most important part (in terms of trust) of the protocol. The client (browser) needs to confirm that the server is who it claims to be. The server provides to the client its certificate for this proof. The client then does a number of checks on the certificate such as:
Does it have a valid chain of trust?
Is the root signature authority a trusted authority by the client?
Is the certificate within its period of validity?
Has the certificate been revoked? (this check is not always possible)
And a few other checks. Once the client trusts the certificate, it can then use it to establish a session with the the server using its public key. The creation of the session involves sharing symmetric keys (note the plural) for the remaining communications.
During the session, two types of security are enforced: privacy via encryption and message integrity via MAC (typically HMAC). The MAC is a symmetric method for computing signatures on every message using a shared secret key (one of the keys that was shared during the creation of the session). This prevents a 3rd party from altering the messages in transit.
You ask how "message digest is considered digital signature?" I think you are referring to the MAC part of the protocol in your question. For more information, see Wikipedia.
I'm a bit confused about using OpenSSL in my Delphi webservice in relation to the available ciphers for a HTTPS connection.
Setup:
My webservice runs on a client's server. OpenSSL is installed there. The webservice uses Indy (a TIdHTTPWebBrokerBridge) and the OpenSSL DLLs (with TIdServerIOHandlerSSLOpenSSL) to load the client's certificate
Our Android/iOS apps connect to this webservice over HTTPS
The client has configured a domain and IP that the app users can connect to and reach my webservice. If we test that domain using e.g. the SSLLabs server test we get an overview of the supported ciphers and protocols (SSLLabs even mimics handshakes from devices and browsers and shows what ciphers were negotiated).
Question: Is there anything my webservice (in combination with OpenSSL) has to do/can do to influence the available ciphers for the TLS handshake between app and webservice? Is there anything additional that needs to be setup with OpenSSL?
I thought the answer is 'no', i.e. that it is just the server setup that (in the handshake with the app through Android/iOS) determines which cipher to use from the available server ones. Is this a correct assumption? Or do I miss something?
(As a matter of fact, I am not actually interested in limiting or expanding the available ciphers, but the client insists that something "should be done" in/with the webservice/OpenSSL to have it communicate "safely" with the apps. The SSLLabs test shows that their domain only supports TLS 1.0 and ciphers with the RSA key exchange mechanism, so e.g. no Perfect Forward Secrecy. To me, that looks like something that needs to be fixed anyway).
Notes:
This SO question suggests I may have to do something, but it has no answers.
I posted an earlier somewhat related question, but that has no answers.
This SO post states OpenSSL honors the client's cipher preference, not the server's, during the SSL handshake, which again suggest there are things I can do?
I had some doubts whether this question is in the proper place here (also because Why we are not customer support), but since this may be relevant to more programmers I decided to put it on SO.
You can specify available ciphers via TIdServerIOHandlerSSLOpenSSL.SSLOptions.CipherList (as well as SSL/TLS versions via TIdServerIOHandlerSSLOpenSSL.SSLOptions.SSLVersions).
If you want Perfect Forward Secrecy, you has to create DHParam keys using openssl.exe (fill TIdServerIOHandlerSSLOpenSSL.SSLOptions.DHParamsFile by result file name). If you want not only DHE, but ECDHE ciphers you need to call some additional openssl api, see a Support for Perfect Forward Secrecy in SSL with indy 10 for example.
I'm running a small web app on an EC2 instance and I want some friends to be able to use it. I also want to make it use HTTPS, just for basic security purposes (prevent packet snooping whenever possible). Of course I am using a self-signed certificate, because my budget for this project is $0. But Chrome throws up a warning page upon trying to visit it:
Your connection is not private
Attackers might be trying to steal your information from [...]
(for example, passwords, messages, or credit cards).
NET::ERR_CERT_AUTHORITY_INVALID
This server could not prove that it is [...]; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
Is is not true that "any encryption is better than no encryption"? On unenecrypted HTTP, I could be trying to steal information as well, and don't have to prove anything about my server identity, AND my communication can be read in plaintext by packet sniffing, but Chrome doesn't throw up any warning flags there...
What gives? Why does Chrome hate self-signed certificates so much? Why doesn't it just put a little red box over the padlock icon, instead of giving me a two-click warning page?
Edit Sep 2021 (this was applicable since 2016): Just suck it up and use one of the free key issuers. Let's Encrypt and AWS ACM will literally do it for free.
This question is not specific to chrome. Firefox and probably other browsers behave similar and in the last years the warnings even got stricter. Complaining about these warnings shows more a missing understanding of the role of certificates in HTTPS.
With HTTPS one expects encryption, i.e. private communication between the browser and the server with nobody sniffing or manipulating the transferred data. At the beginning of the encryption client and server exchange the encryption keys, so that one can encrypt the data and the other can decrypt the data. If some man-in-the-middle manages to manipulate the key exchange in a way that it gets control over the encryption keys, then the connection will still be encrypted but not private. Thus it is essential that the key exchange is protected and this is done with certificates. Only with proper checking of the certificates the client can verify that it talks to the server and not some man-in-the-middle and thus the critical key exchange can be protected.
Certificates are usually verified by
Checking the trust chain, i.e. if the certificate is directly or indirectly (via immediate certificates) issued by a certificate agency (CA) trusted by the browser or operating system.
Verifying that the certificate is issued for the expected hostname, i.e. the subject matches the hostname.
With self-signed certificates or certificates issued by a CA unknown to the browser/OS this check will fail. In this case it is unknown, if the original certificate was already not issued by a trusted CA or if there is some man-in-the-middle manipulating the connection. Being man-in-the-middle is not hard, especially in unprotected networks like public hotspots.
Because the browser can not verify the certificate in this cases it will throw a big fat warning to show the user that something is seriously wrong. If your friends know that you only have some self-signed certificate there they should also know that this is the expected behavior of the browser in this case. You also should provide them with the fingerprint of your certificate so that they can be sure that this is the expected certificate - because there is no other way to check the validity of this certificate. Note that this warning also comes once because the browser saves the fingerprint and from then on knows that your site is associated with this certificate. But if you change the certificate it will complain again.
If you don't like the trouble of teaching all of your friends how to properly verify your certificate then get yourself a certificate by a public CA. They don't need to be expensive and some also issue free certificates.
Is is not true that "any encryption is better than no encryption"?
While bad encryption might be better than no encryption, transferring sensitive data over en encrypted but man-in-the-middle connection is definitely worse then transferring non-sensitive data with no encryption. And contrary to plain HTTP you can actually detect a potential man-in-the-middle attack with HTTPS. What you can not do is find out if this a potential man-in-the-middle attack or if the non-verifiable certificate is actually the expected, because the browser has no previous knowledge what to expect. Thus a self-signed certificate is actually not that bad provided that the browser knows up-front that this site only provides a self-signed certificate. And it might also not bad if the transferred data are not sensitive. But how should the browser know what kind of data and what kind of certificate are to expect?
Because SSL/TLS are trying to solve two problems in a single stroke, but you are completely ignoring one of them.
SSL is meant to provide both encryption (between two endpoints) and authentication (where each endpoint is exactly who it says it is). This latter solution is generally meant to be solved via organizations known as Certificate Authorities (CAs), who are supposed to verify your identity before agreeing to give you a certificate. While there have been some spectacular failures of this level of trust in the past, we don't have anything better yet, and so browsers still expect to see SSL/TLS certificates to be issued by one of these Trusted authorities; if it's not, there's no way to know if you're actually talking to the party you intended to.
So, while it may be encrypted, having an encrypted conversation with someone who shouldn't be party to the conversation is actually WORSE than having a plaintext conversation with someone who SHOULD be party to the conversation.
There are a few free SSL providers out there such as Let's Encrypt that won't cause this warning and still fit in your $0 budget.
Put chrome://flags/#allow-insecure-localhost into the Chrome address bar, then select the enabled option.
The reason for the click through is to offer some protection from phishing attacks.
The $0 work-around is to create a certification authority verified by Justaskin_ (which is just a special file) and have your friends to install the public key derived from of it on their computers.
Instead, use the private key to sign your https certificate and their browsers will accept it. OpenSSL is one tool that can do this.
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.