I have configured a web application with TLS 1.0. My requests are going in the encrypted format through out the channel, which is secured for from the man in the middle attack. TLS is working on RSA mechanism, so the doubt is if the network admin (having the private key) will be able to decrypt the request or not.
First, system or network admin do not have access to the private key if you add an HSM and configure your web server to use it (see https://en.wikipedia.org/wiki/Hardware_security_module).
Secondly, many PFS cipher suites are available with TLS 1.0 (see https://security.stackexchange.com/questions/74270/which-forward-secrecy-cipher-suites-are-supported-for-tls1-0-protocols), so if you only accept such cipher suites on your web server, somebody that can capture your communications and that knows the RSA private key will not be able to decrypt the content of the channel: the cipher key used to protect the channel is ephemeral, it is not your RSA private key.
Related
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
OPC UA allows for using different certificates and private keys for establishing the secure channel and for creating the session, i.e. authenticating the client.
I'm creating a client to connect to an OPC UA server and I'm trying to keep thins as simple as possible, therefore I'm considering allowing to set just a certificate and private key, and if certificate authentication is desired then re-use that very cert. and private key.
Is this a safe assumption or are there real world reasons not to couple the secure channel and the session to the same certificate?
That's how the applications usually do it, when using UA TCP transport protocol, so yes.
With HTTPS transport, you will need a separate certificate for transport and authentication. But HTTPS is optional.
In an Android client that I wrote, in the settings, the user can choose the common name of both certificates and they are automatically created
That helps the server administrator to identify who the connection attempt corresponds to, although if the user puts the same name for both then the same cert is used for the secure channel and session.
Is it possible in SSL/TLS handshake where client only send its certificate. Server need not to send any certificate ?As of now in one way handshake only server send its certificate to client.
As i am aware of that in this scenario server needs to maintain all clients root certificate(if diffrent).This is not practical.If possible what are the security concerns.
Here is context under Use of SSL with socket programming in C# or C++
Thanks for help!
Yes, it is possible to use SSL/TLS without a server certificate. See https://security.stackexchange.com/questions/38589/can-https-server-configured-without-a-server-certificate
You need software that supports at least one of the anonymous cipher suites SSL/TLS supports, such as TLS_DH_anon_WITH_AES_128_CBC_SHA256. Per the OpenSSL Diffie Hellman wiki entry:
Anonymous Diffie-Hellman uses Diffie-Hellman, but without authentication. Because the keys used in the exchange are not
authenticated, the protocol is susceptible to Man-in-the-Middle
attacks. Note: if you use this scheme, a call to
SSL_get_peer_certificate will return NULL because you have selected an
anonymous protocol. This is the only time SSL_get_peer_certificate
is allowed to return NULL under normal circumstances.
You should not use Anonymous Diffie-Hellman. You can prohibit its use
in your code by using "!ADH" in your call to SSL_set_cipher_list.
Note that support for such cipher suites and configurations in most available SSL/TLS software is either non-existent or very limited, as such configurations are vulnerable to man-in-the-middle attacks - one of the very things SSL/TLS is used to prevent. You'd have to compile your own OpenSSL code, for example.
Unless you control the software at both ends of your communication channel(s), effectively there's no way to implement such a system.
And there's no real reason to implement such a system as it's not secure at all.
But you can do it with a lot of effort.
Server Certificate which contains the public key part of its key pair is must. The client may decide to overlook the authenticity of the certificate( Its bad!) but the TLS handshake requires the public key for the generation of pre-master-secret. So no way you can prevent server from sending the certificate.
Server if it wishes can request client for its certificate. This is for authenticating the client.
I am trying to make REST calls to server from a client.
Server Side
I am using Flask as web server. I have generated the certificate(cert.pem) and public key(key.pem) using the following command.
openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365
Following is the server side code.
from flask import Flask
from flask_restful import Resource, Api
app = Flask(__name__)
api = Api(app)
class HelloWorld(Resource):
def get(self):
return {'hello': 'world'}
#app.route('/someroute/<arg1>,<arg2>', methods=['GET'])
def fn1(arg1,arg2):
res = fn2(arg1, arg2)
return str(res)
def fn2(un,pwd):
#Do something and return a number
return num
if __name__ == '__main__':
context = ('cert.pem', 'key.pem')
app.run(host="ip", port=port1, debug=True, ssl_context=context)
Client Side
I have a flask application from which I need to make REST calls to the above server. Following is the code I am using to do so.
import requests
# Below is the part of a function which gets called upon hitting a route in Flask.
ret = requests.get("https://<ip>:<port1>/<someroute>/arg1,arg2", verify=True)
print ret.text
This is throwing the following error.
requests.exceptions.SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
This error is expected as the certificate is not known to the client. Everything is working perfectly fine if I skip the certificate verification (verify=False).
How do I make the client trust this unknown server SSL certificate? I have seen solutions where I need to use Nginx on the client side. Can we not do some changes on flask(client side) itself to make it trust my server? If yes, what is that exact change I should be making in Flask? Also, suggest if urllib is better than requests.
UPDATE 1
I have another query here. From above, I understood that requests.get verifies the certificate every time we make a REST call (Please correct me if I am wrong). But, this looks like an extra load. Can we not have an encrypted connected established in the beginning and exchange the data by encrypting it with a private key? So, how to implement the beginning part - Send private key by encrypting it with the public key to the server and then start exchanging data by encrypting the data with the private key.
OC (original comment):
Server Side
I am using Flask as web server. I have generated the certificate(cert.pem) and public key(key.pem) using the following command.
openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 36
If you read man req it says,
-out filename
This specifies the output filename to write to or standard output by default.
-keyout filename
This gives the filename to write the newly created private key to. If this option is not specified then the filename present in the configuration file is used.
Here, cert.pem could be referred to as the public certificate and key.pem really is your private key (Keep it safe and well, private). FTFY.
OC (original comment):
This error is expected as the certificate is not known to the client. Everything is working perfectly fine if I skip the certificate verification (verify=False).
How do I make the client trust this unknown server SSL certificate? I have seen solutions where I need to use Nginx on the client side. Can we not do some changes on flask(client side) itself to make it trust my server? If yes, what is that exact change I should be making in Flask? Also, suggest if urllib is better than requests.
I'll answer this backwards, but first a little background. I found these links really useful to understand - on a high level - how the SSL/TLS handshake happens and how authentication is carried out
IBM: An overview of the SSL or TLS handshake
IBM: How SSL and TLS provide authentication
Now, coming back to your question,
requests > urllib (Personal opinion, but requests does have a good support and is mature - not implying that urllib isn't)
It looks like you want to do server authentication only, for that your client needs the server's public certificate. From How SSL and TLS provide authentication:
The certificates required are as follows, where CA X issues the certificate to the SSL or TLS client, and CA Y issues the certificate to the SSL or TLS server:
For server authentication only, the SSL or TLS server needs:
The personal certificate issued to the server by CA Y
The server's private key
and the SSL or TLS client needs:
The CA certificate for CA Y
Use it in requests.get referring this from requests, which says,
You can pass verify the path to a CA_BUNDLE file or directory with certificates of trusted CAs:
requests.get('https://github.com', verify='/path/to/certfile')
Once you do that and have good certificates, it should work.
NOTE: The openssl command in the OC does not show any subject for the key/cert pair, this would still fail cert verification, refer documentation that shows how to generate self-signed certs. There's a requirement to provide SANs (SubjectAltNames) so providing just a CommonName (CN) in the subject won't future proof your process.
EDIT:
The CA talk in the IBM document can be confusing, but since this is a self-signed cert, you don't have to worry about this, just think of it as your Flask server being the SSL/TLS server, and any client of that server can do server verification using server's public key.
OC (original comment):
From above, I understood that requests.get verifies the certificate every time we make a REST call (Please correct me if I am wrong). But, this looks like an extra load.
That's true. It would perform verification each time. To avoid that you can use requests.Session() as mentioned in requests SSL Cert Verification
OC (original comment):
Can we not have an encrypted connected established in the beginning and exchange the data by encrypting it with a private key? So, how to implement the beginning part - Send private key by encrypting it with the public key to the server and then start exchanging data by encrypting the data with the private key.
This is explained really well in the IBM docs listed
We are doing a project in Scala, using Lift to provide some REST style web services for clients (Java-script through AJAX). For some business reasons we decided to put it all under SSL but I'm am not sure where to start. Insights would be much appreciated.
Whatever server software is currently handling HTTP traffic (e.g. Jetty, Nginx, Apache...) almost certainly has some means of adding SSL support and disabling plain HTTP; try that first.
As for the basic mechanism of adding SSL support, it goes something like this:
Generate an RSA keypair (the key size should be at least 1024 bits). This step should prompt you to fill in some information about you, your organization, and the server's hostname ("common name" in X.509 parlance). It should also prompt you for a passphrase, which will be used to encrypt the private key.
The keypair consists of a private key (this is the part you shouldn't share with anyone) and a self-signed certificate, which contains, along with other metadata, the public key.
If you want to get a real cartel-signed SSL certificate, so that members of the general public won't see nasty warnings when they visit your site, you'll need to generate a Certificate Signing Request (CSR) from your keypair and submit that to an SSL certificate authority, who will create a certificate derived from your CSR, but signed with their private key. Luckily, in recent years, the SSL CA business has gotten extremely competitive, so pricing shouldn't be a major hurdle anymore.
If you're not planning to get a real cartel-signed SSL certificate, you can use the private key and self-signed cert as-is.
Either way, you need to tell your web server how to find the certificate (whether self-signed or CA-signed) and private key. Apache HTTPD prefers to keep the two things in separate files; most JVM servers prefer that they be encapsulated in a keystore. The best keystore format for general use is called PKCS#12, it's an industry standard. Making a PKCS#12 file out of a separate key and cert is a bit tricky, look on ServerFault if you can't figure it out. :)
You usually want to put the private key passphrase in the server's configuration file, so make sure that configuration file (and the file containing the private key) have the most restrictive permissions that will still work.
This depend on which application server you're running.
Jetty: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
Tomcat: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
Glassfish v2: http://blogs.oracle.com/enterprisetechtips/entry/using_ssl_with_glassfish_v2
Glassfish v3: http://javadude.wordpress.com/2010/04/06/getting-started-with-glassfish-v3-and-ssl/
You're not sure where to start with which bit? The SSL?
Set up stunnel (or similar) in front of your webapp, and firewall your webapp off so that only stunnel can access it. Then your clients can only access your webapp over SSL, via stunnel.