Every month there are articles on the web about some app or platform using outdated crypto configurations in its SSL implementation. This has gotten me worried... what about my own implementations?
What exactly should I do to configure OpenSSL in the most secure fashion when I use it in an app for serving and/or consuming HTTPS? (e.g. in combination with cURL)
Aside from configuration, what other steps must be taken to ensure that OpenSSL is used securely? Are there any special steps I should take, e.g. in relation to the public key infrastructure?
Is there some "known good" configuration available on the web?
Ensure that your certificate provider signs your certificate with a SHA1 or better (SHA2 preferred) hash.
HTTPS (SSL/TLS) is only effective if you verify the certificate. This is most commonly performed by the client. If the client does not verify the identity of the server by verifying the certificate, you are subject to man in the middle attacks.
You can configure the server so that it does not allow the older (SSL) protocol, and instead requires the latest TLS protocol, which is cryptographically stronger (e.g. SHA1 and MD5 in the pseudo-random function instead of just MD5 in TLS 1.0, and TLS 1.2 uses SHA2).
When creating your certificate key pair, choose a longer key (e.g. 2048 bit is preferred over 1024 bit).
There are some good recommendations on the Mozilla wiki:
Security/Server Side TLS
Related
Usually when a user logs in, the user details are sent to the sever to authenticate the user. How are these credentials protected in the best way during flight?
Main Questions :
I understand the passwords are many times hashed, keeping them secure. Also TLS maintains the in-flight security, But is that the only way the transaction details are kept secure or do websites add any of their own layer of security?
In our case, we want to send a passcode to the backend, where another API will be called (that uses password grant) of a third party application. We cannot hash the password, we'll need it in the backend. Will TLS be sufficient for securing it in flight?
We were also planing to implement and secure the passcode by RSA (public key) on the client side and unlock it on the backend for use. Should we consider RSA?
I understand the passwords are many times hashed, keeping them secure. Also TLS maintains the in-flight security, But is that the only way the transaction details are kept secure or do websites add any of their own layer of security?
There are very few cases where layering more cryptography on top of TLS are beneficial. Your case doesn't seem to fit them. So TLS should be enough. TLS already provides encryption in transit. RSA would do the same. Defense in depth means layering different security mechanisms on top of each other.
You might hash the password on the client side creating an intermediate password, but considering your 2. question, this is not what you can do.
In our case, we want to send a passcode to the backend, where another API will be called (that uses password grant) of a third party application. We cannot hash the password, we'll need it in the backend. Will TLS be sufficient for securing it in flight?
Yes, but let the client (your server) validate the certificate chain and don't accept protocol downgrades.
We were also planing to implement and secure the passcode by RSA (public key) on the client side and unlock it on the backend for use. Should we consider RSA?
No, just use TLS 1.2 or higher with a valid server certificate and let the client validate the certificate chain (browser does that automatically for you).
Keep in mind that TLS needs a trust root. Most client side libraries as well as many browser use the trusted root store of the operating system. A certificate chain presented by the server should end in one certificate that is in the trusted root store.
You could use a self-signed certificate, but then the client would need to pin the public key of that self-signed certificate.
I have a question regarding SSL verification within the requests library for Python, but I believe it to me more general than that.
I am currently ignoring certificate verification because the third party API I need to connect to is using a self-signed certificate.
What are the implications for turning SSL verification off in requests? And what are the implications for not verifying SSL certificates in the real-world. Can I gaurantee the data transported is secure/encrypted?
This is a security sin, as anyone could spoof this certificate and intercept your traffic. You should just add the self-signed certificate to the trusted certificate chain of the machine which is using the API.
How you do that depends on the operating system and specific setup, but a quick google will guide you to the right solution.
Can I gaurantee the data transported is secure/encrypted?
The data is encrypted (this is TLS confidentiality guarantee) but since you did not authenticate the remote part (if you disable certificate validation or bypass all errors) you could be as well sending the encrypted content to anyone, including an attacker, which of course on his side will read it in plain, as the TLS handshake succeeded if you do not validate the remote party.
TLS provides multiple features, two major ones being authentication and confidentiality. They are orthogonal (you can have one without the other) but it may not be so useful to not have all of them.
Contrary to natural thinking, authentication is more important than confidentiality because if you have no insurance about who is the remote party, what do you gain by sending it encrypted? Nothing.
Need to know if we can enable TLS 1.2 cipher suites for SHA1 certificates for communication with managed servers in weblogic Application server?
enable TLS 1.2 cipher suites for SHA1 certificates
There is no such thing as a cipher suite for SHA1 certificates.
The cipher suite only specifies the authentication method which essentially specifies the type of certificate to use, i.e. typically RSA or ECDSA. The cipher suite itself makes no restrictions on the signature algorithm usable in the certificate, although such restrictions might be given in the TLS handshake using the Signature Algorithms extension in the TLS handshake - but this is not part of the cipher.
The cipher suite still contains some hash algorithm. But this is not used to specify the signature algorithm but instead the hash used inside the HMAC, i.e. message integrity and not authentication.
The digest algorithm that was used to sign your server certificate has no influence whatsoever on the TLS version that you want to use.
So short answer: Yes, you can use a X.509 certificate that was signed using SHA-1 for a TLS v1.2 session
The problem with SHA-1 based certificates is on the client side. The client (ususally: web browser) has to decide wether it trusts the server's certificate or not. And most current browsers do not trust any SHA-1 certificates anymore, no matter if the session uses TLS 1.2 or an older version.
I have a scenario where I have 2 applications.
The service, providing some data
The UI client, displaying the data from the service
I want the communication between the service and the client to be secure (encrypted).
What should I use for that? Is the SSL common protocol for such usage, or do we typically use something else?
Assuming your service is exposing a standard REST API (or similar) that your front-end is calling: yes, SSL is the standard. It provides:
Confidentiality: the data is encrypted between the client and the server and cannot be read by an attacker. Typically uses the RSA algorithm.
Integrity: an attacker cannot tamper with the messages sent between the client and the server. Typically implemented using HMAC
Authentication: the client is able to check that the server it is talking to is actually yours, and not an attacker. Basically, the server shows to the client a certificate signed by the Certificate Authority having issued the SSL certificate (e.g. VeriSign), that proves its identity.
All that is assuming SSL is configured properly on the server's side: up-to-date ciphers, no support for outdated ones, proper key length (2048 bits or higher), etc.
Note that a client can be anything calling your service: a browser-based application, a mobile application, a smart watch application...
You can use SSL Labs to check if your SSL configuration looks secure.
Recently I heard that Flame used MD5 checksum collision to tamper with Microsoft update.
My question is where does the MD5 checksum come into play?
From this source on Microsoft website:
Windows Update uses the Secure Socket Layer (SSL) protocol to send and receive information.
Each update is individually signed using the Secure Hashing Algorithm (SHA-1).
So where is MD5 used, is it used for authenticating the update site?
In the context of FLAME, MD5 hash collision was exploited to forge an intermediate certificate in the PKI rooted at Micosoft. The clients rely on such PKI to validate an update file really comes from Microsoft.
The certificate associated to the actual fake update file may have been signed using SHA-1 or any other strong hash algorithm. The problem is that an existing genuine intermediate PKI CA entity had its certificate signed with MD5. The attackers exploited the weakness of such algorithm to forge a second PKI CA certificate that they could use to further sign anything they liked.
SSL was not directly used in the attack (the Windows Update mechanism allows packages also from non-SSL sites).