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.
Related
I don't understand what is the actual need of having FabricTLSCA if we have PKI in place for secure communication. My assumption is that TLSCA is required for secure communication between different components. For example cert for my domain *.abc.com can be used using PKI than why Fabric TLSCA is required to give certificates.
You are not required to use the Fabric CA for issuing TLS certificates. You can use your own CA as well. You can even use 3rd party TLS/SSL certificate issuers such as Let's Encrypt, DigiCert, Verisign, etc as well. If you choose to use mutual TLS, you may want not want to use a public 3rd party service if you are looking to to added authentication, but generally speaking it is unnecessary to use mutual TLS in any case.
TLS CA is used for TLS communication between components. Communications are encrypted end to end via TLS so that they can not be disclosed. Certificates signed by TLS CA are valid during TLS handshake.
Regular MSP CA is used for authentication, membership... Signatures in Fabric are validated as the certificates used for signature are signed by MSP CA.
Both CAs can be the same. They can be different, too.
Let's assume we have 2 CAs "ACA" using RSA and "BCA" ECC, both issuing TLS certificates for the server. ACA is trusted by most clients while BCA is only trusted by only a few.
While ACA is trusted, RSA always takes more time. So we'd want the cert signed by BCA to be preferred by all clients that trust BCA while the others would fall back to the ACA one.
As I know, configuring multiple certificates for a domain is possible. At least on nginx, but the client always uses the certificate I have put a as the second certificate entry in the snginx.conf configuration file of nginx.
So is it possible that the server handles delivering the EC certificate if possible, but the RSA one if the client does not trust the certificate?
The client does not provide any information which CA it trusts. This means that the server can not decide which certificate to serve based on the clients trust settings. The only information the server has to decide which of these certificates to use is to look at the ciphers offered by the client, i.e. use the ECC certificate if the client supports ECDSA ciphers and use the RSA certificate otherwise.
Asymmetric encryption solves the trust problem inherent in symmetric encryption by using two different keys: a public key for encrypting messages, and a private key for decrypting messages. This makes it possible to communicate in secrecy with people you don't fully trust. RSA is a cryptosystem for public-key encryption, and is widely used for securing sensitive data.
I checked the dotnetnuke source but I don't know dotnetnuke uses RSA for asymmetric encryption or not?
It would be very helpful if someone could explain asymmetric encryption method in dotnetnuke.
Thanks.
DotNetNuke doesn't use any asymmetric cryptography by itself. It uses some hash functions like MD5 (bad) and SHA-256 as well as symmetric encryption like two-key 3DES (very bad) and AES.
The only thing is that you can configure to use transport security (SSL/TLS) which includes various types of asymmetric cryptography. In SSL/TLS, client and server can negotiate a cipher suite depending on both their capabilities. You need a private key and a certificate (which contains the signed public key) in order for the connection between client and server to be encrypted.
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
I want to apply web service security according to OWASP Web Service Security. Thereby I stumbled over the two points:
Message Integrity
Message Confidentiality
So far there is just a RESTful service which can be directly accessed by a client. For each request the client needs to authenticate by the server. All communication is secured via TLS. I'm now unsure about Message Integrity since I don't understand the sentence:
When using public key cryptography, encryption does guarantee confidentiality but it does not guarantee integrity since the
receiver's public key is public. For the same reason, encryption does
not ensure the identity of the sender.
Is it also required that the data was signed by the client in order that message integrity is ensured? TLS is only point-to-point, what is about proxies?
Concerning Message Confidentiality, I understood it as follows.
Use TLS to ensure message confidentiality over the wire.
Use a symmetric encryption to encrypt the transmitted data.
The encrypted data get stored in data base.
Did I understand that right?
From the TLS specification:
The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. [...]
The connection is private. Symmetric cryptography is used for
data encryption (e.g., DES [DES], RC4 [SCH] etc.). [...]
The connection is reliable. Message transport includes a message
integrity check using a keyed MAC. Secure hash functions (e.g.,
SHA, MD5, etc.) are used for MAC computations. The Record
Protocol can operate without a MAC, but is generally only used in
this mode while another protocol is using the Record Protocol as a
transport for negotiating security parameters.
So, yes, TLS will provide you with integrity and confidentiality of the message during its transport, provided that it was used correctly.
In particular, the client needs to verify the certificate to ensure it is communicating with the right server (verifying that the certificate is genuine and issued by a trusted party, and issued to the host name it intended to contact).
Use TLS to ensure message confidentiality over the wire.
Use a symmetric encryption to encrypt the transmitted data.
TLS will provide confidentiality via encryption. (You need to use an appropriate cipher suite, in particular not a anonymous cipher suite or a cipher suite will null encryption, but that's always the case by default.)
The encrypted data get stored in data base.
If you want to encrypt the data in your database, that's a different problem. TLS only provides you with integrity and confidentiality during transport. Once it's handled by your web application, it's deciphered.
TLS is only point-to-point, what is about proxies?
HTTP proxies only relay the TLS traffic as-is, without looking into it or altering it. (Some proxy servers can intercept the traffic, but the certificate verification would fail, unless you forget to check the certificate.)
Does TLS ensure message integrity and confidentiality of data transmission
Yes.
in a RESTful Java enterprise
Irrelevant. Answer is still yes.
When using public key cryptography, encryption does guarantee confidentiality but it does not guarantee integrity since the receiver's public key is public. For the same reason, encryption does not ensure the identity of the sender.
Irrelevant. TLS isn't public-key cryptography. I really fail to see the point of these remarks in this context, but they're not correct. No form of encryption alone guarantees either integrity or identity: you need additional measures for that; and the key being public is irrelevant to that as well.
Is it also required that the data was signed by the client in order that message integrity is ensured?
No. A secure HMAC will do as well, and TLS uses one of those. TLS does use digital signatures during the authentication phase.
TLS is only point-to-point, what is about proxies?
Proxies are either trusted TLS endpoints of their own or else transparent byte-passing proxies that therefore preserve the properties of TLS between their peers as endpoints.
Concerning Message Confidentiality, I understood it as follows.
Use TLS to ensure message confidentiality over the wire.
Correct.
Use a symmetric encryption to encrypt the transmitted data.
TLS does that.
The encrypted data get stored in data base.
No. The encrypted data gets decrypted by the peer off the wire. The peer can re-encrypt to the database, or the database can do it, but that's a separate issue.