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.
Related
I am trying to set up MTLS on a Jetty Server. From the documentation I have seen typically the server certificate is set up such as this
SslContextFactory.Server sslContextFactory = new SslContextFactory.Server();
sslContextFactory.setKeyStorePath("/Users/name/Downloads/server.jks");
sslContextFactory.setKeyStorePassword("changeit");
sslContextFactory.setTrustStorePath("/Users/name/Downloads/server_truststore.jks");
sslContextFactory.setTrustStorePassword("changeit");
sslContextFactory.setNeedClientAuth(true);
However, I want to have different server certificates to validate against depending on which device sent the client certificate? What settings do i need to change, or classes can I override to dynamically validate certificates?
You'll have to download it and then configure your SslContextFactory.Server to use the local copy.
This is a Java SSL engine limitation.
Use the prior answer on how to download a file from Amazon S3 ...
https://stackoverflow.com/a/28569038/775715
For mTLS, just set the SslContextFactory.Server features you want to use for your set of features.
SslContextFactory.Server.setNeedClientAuth(boolean)
This is the javax.net.ssl.SSLParameters.setNeedClientAuth(boolean) feature in the Java JVM.
SslContextFactory.Server.setWantClientAuth(boolean)
This is the javax.net.ssl.SSLParameters.setWantClientAuth(boolean) feature in the Java JVM.
The behavior is standard Java JVM behavior, Jetty does very little here (Jetty only configures the JVM SSLEngine and SSLParameters objects, and handles host/alias matching if using SNI), all of the mTLS behaviors are baked into the JVM.
Everything from this point forward is standard Java behaviors of Client Auth, and Server Keystore/Truststore, there is nothing unique or special about Jetty. It's all a matter of configuring your Keystore/Truststore and issuing valid client certificates from those stores.
If you want multiple server certificates, go for, that's supported by the keystore / truststore.
If you want the client to validate against different server certificates, then the client needs to use the appropriate combination of server hostname and SNI information (this is an extremely common TLS extension).
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");
I want a client/server C++ application that can use TLS for secure communication, including client certificates, and potential to select and validate certificates myself.
I have used Schannel to do this before, but the key InitializeSecurityContext is marked [desktop apps only].
Have Microsoft provided a new equivalent API?
Although in theory I could replace the whole thing (since in the end, I can still have a normal plaintext TCP socket) I would rather stick to OS components if possible.
I have a SOAP webserver developed in Delphi XE2 that exposes some methods and it uses SSL. I built my client also in Delphi XE2, and I use THTTPRIO to connect to webserver. My question is related to the use of SSL certificatest with THTTPRIO. If I call my webservice it works without having a certificate installed, but I think that it shouldn't.
Second scenario :I have a self signed certificate which I installed it and after I made a call to my webservice it works also.
When I inspected my events: HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest and SOAPResponse to string from TStream and seems that it isn't encrypted in both cases. I also found on another forum the same question but with no response.
I searched for info about SOAP SSL Clients with Delphi but couldn't find any new info. Could any of you guys give me some advices regarding this issue?
If I call my webservice it works without having a certificate
installed, but I think that it shouldn't.
Not many web services require client certificates (with exceptions like banking and other high risk environments). It is more common that clients want to verify the server identity, and this is done with server certificates.
So I would say this web service does work in a normal, expected way.
HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest
and SOAPResponse to string from TStream and seems that it isn't
encrypted in both cases
This is correct, the message payload will appear unencrypted because SSL / TLS does encryption on the transport layer. Your application will not see the encrypted data, which actually makes things easier.
You can add encryption for the message payload, there are generic libraries for this (however I have no experience with using encryption HTTPRio).
I have two computer systems each having an apache server. One machine is a client machine and the other is a server machine. I want both the client request and the server response to be encrypted thus making the data transfer safe.
Could someone please give pointers/steps on how I could make progress in this front.
The communication doesn't involve any GUI components meaning the communication is purely a backend one.
Both the client and the server are coded in java. I am using Axis2 and jaxws for the communication.
Currently I am able to send the client request and receive the server response without SSL enabled. Now If I enable SSL does it mean that I should also modify the existing code according to the SSL or the current working code still holds good.
You have many options here. Since you mention SSL...
On each server generate an asymmetric key-pair (RSA 2048 is a safe choice). Then create a self signed certificate on each server. Then copy each certificate to the other machine and mark it as trusted by the Java environment that apache is using and that NONE OTHER are trusted. Configure SSL/TLS on each of the apaches to use a good symmetric cypher (3DES is a safe choice, but there are other newer ciphers if you want leading edge). Next ensure that all access between Tomcat servers is via https URLs and you should be in decent shape.
An alternative is to use IPSEC to establish a static tunnel between the two servers using certificates or other trust bases.
One fairly simple option is to use stunnel, which is available via the standard package-manager on most *NIX systems. You configure an stunnel as a client (and server if you with) on one server and then another as the server (and client if you wish) and then configure your Tomcat instance(s) to connect to localhost:XYZ where XYZ is the port where stunnel is listening.
The nice part about using stunnel is that you can use it to tunnel any protocol: it is neither a Tomcat-specific nor a Java-specific technique, so you can use it for other applications in the same environment if you want.