I have a challenging question. How can I define new ciphersuites such as an encryption scheme A with AES256 (Hybrid) in combination with a Signature scheme B in order to operate it with Bouncycastle TLS 1.3 or TLS 1.2.
I do not want to use predefined ones from bouncycastle.
What are the steps towards doing this? Is there a fast way?
The same also for JCE?
Many thanks for your great help.
Related
Is there a difference between certificates, let's say from Apple for signing or Let's Encrypt for TLS/SSL? Are they interchangeable or when generated do they have specific params that make one good for ID and one good for encryption?
Depending on what you mean, they're either exactly the same, or they're different. (Isn't language grand?)
A code-signing certificate and a TLS server certificate and a TLS client certificate are all X.509 Public Key Certificates, described by IETF RFC 5280 and ITU-T X.509 (whence the name).
Within the certificate there's a(n optional) set of extensions (the well-defined ones were extending the rigid structure of the previous data versions). One of these extensions is called Extended Key Usage (which, confusingly, is described by X509EnhancedKeyUsageExtension in .NET), generally abbreviated as EKU. The EKU extension is just a list of identifiers that indicate to what purposes the certificate is valid. (Organizations like the CA/Browser Forum come up with rules for what a CA has to do before allowing each specific type of purpose to be claimed.)
The current certificate I see for stackoverflow.com has two listed purposes: 1.3.6.1.5.5.7.3.1 and 1.3.6.1.5.5.7.3.2. Those identifiers don't mean much to the general population, though, so many systems will replace them with friendlier names. Firefox 89's description is "Server Authentication, Client Authentication".
TLS/SSL have a lax approach to EKU: If the certificate has an EKU extension then the TLS Server (1.3.6.1.5.5.7.3.1) or TLS Client (1.3.6.1.5.5.7.3.2) purpose must be present (the correct one for the role it's taking), but if the EKU extension isn't present then the certificate is acceptable.
RFC 3161 Timestamping is less lax. It requires that the certificate have an EKU extension (and only one of them, which can contain multiple purpose values) which contains the purpose 1.3.6.1.5.5.7.3.8, in section 2.3.
So, the differences are just in EKU values.
TLS Server: 1.3.6.1.5.5.7.3.1
TLS Client: 1.3.6.1.5.5.7.3.2
Code Signing: 1.3.6.1.5.5.7.3.3
Timestamping: 1.3.6.1.5.5.7.3.8
There are a lot of others in general use, like 1.3.6.1.4.1.311.10.3.5 (Microsoft Windows Hardware Quality Labs Driver Verification), they don't all start with "1.3.6.1.5.5.7.3." (though a good number of the common ones do).
I am learning TLS mutual authentication using Openssl.
During the TLS handshake process, I want to run the code I wrote separately for the two processes below.
Part of signing with your private key
Verification part of the certificate received from the other party
Note that I try to do this in a trustzone or a separate secure area.
I'm looking at the openssl content, and I'm not sure which APIs can handle these things.
I do not know how to approach this now.
If anyone knows about this, please reply.
Looks like you have a requirement for using TPM for Private Key. You should take a look at https://github.com/ThomasHabets/openssl-tpm-engine. This could be of some help. Apart from that, there is no known callbacks for Private Key Signing. But, as Steffen Ullrich correctly mentions, the SSL_CTX_set_verify function can help you to add your own logic for validating the certificate received from Peer.
I have a business requirement to use TLS 1.1 or greater and to not use SHA-1 (or RC4).
Are there any known-secure implementations of TLS 1.1 that do not use SHA-1 for the MAC? I can't seem to find any. I am thinking I should just skip past TLS 1.1 at the moment if there are no secure MACs available.
Does openssl have a "raw" (non-EVP) interface to do AES GCM encryption and decryption? I'm looking for something comparable to AES_cbc_encrypt() or DES_ede3_cbc_encrypt(), but for AES GCM. I found the openssl EVP interfaces for AES GCM but I can't find any information on any non-EVP interface.
I understand the EVP interface has many advantages for general purpose use, but I'm doing some tests where a non-EVP interface would be easier to use.
Once I was looking for it and I couldn't find any non-EVP implementation of it. According to the OpenSSL site 'the enc program does not support authenticated encryption modes like CCM and GCM'.
But it seems AES GCM only supported in TLS v1.2 (according to 'https://www.openssl.org/docs/manmaster/apps/ciphers.html').
Is it possible to have a cut down implementation of TLS , where we just
presume the server we are connecting to is trusted - after the server sends its
certificate, can we bypass verification of this and do away with any further
processing , and get right into standard http ? Is using public key encryption
something that is absolutely necessary , or can it be skipped ?
Rewording my question.
Is it possible to write a tls engine by skipping the need to use RSA public key
code ?,
or
Can a client notify the server during the handshake that it just requires the severs certificate
info, company name, expiry dates and requests the secret cipher key to be sent in plain text.
Skipping something in a protocol I don't fully understand is generally a bad idea.
Only steps marked as optional in the RFC can be safely skipped.
Therefore if you don't plan to use client-side certificate based authentication you can skip it.
However what you can do however is limit the number of variations in your implementation. This means support only one TLS version (e.g. TLS 1.2) and support only one dedicated cipher suite.
Anyway the pitfalls when implementing TLS are so numerous that I recommend you to use an existing implementation (e.g. implementing in a way that does not allow side channel attacks is not that simple and requires knowledge on that topic). There are other implementations beside OpenSSL with a much smaller footprint.
BTW: If you can presume the connection is trusted you don't need TLS. If you need TLS it should be a secure.
where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing
The point of verification is less to find out if the server is trusted, but more that you are actually talking to the server you expect to. If you omit this step you are open to man-in-the-middle attacks.
But, TLS is a very flexible protocol and there are actually ways to use anonymous authentication or a shared secret with TLS and thus skip usage of certificates. Of course in this case you would need to have some other way to validate the server, because otherwise you would be still open to man-in-the-middle-attacks. And because this use case is mostly not relevant for the common usage on the internet it is usually not implemented inside the browsers.