Re: x509v3-sign-rsa, x509v3-ssh-rsa and x509v3-rsa2048-sha256

[murugesh pitchaiah]

Thanks for the response Dirk.

I tried, but could not see the certificate public key algorithm - as
x509v3-ssh-rsa or x509v3-rsa2048-sha256.

I use below openssl commands to generate the user certificate:

openssl req -nodes -new -x509 -keyout  userkey.pem -out
userreq.pem -days 365 -config openssl.cnf

openssl x509 -x509toreq -in userreq.pem -signkey userkey.pem -out tmp.pem

openssl ca -config openssl.cnf -extensions  usr_cert -out
usercert.pem -infiles tmp.pem


I tried varying the bits size (1024/2048/4096)  and default_md
(sha1/sha256/sha512) in the openssl.cnf file.

Could anyone please share the steps to generate user certificates of
type: x509v3-ssh-rsa  and x509v3-rsa2048-sha256 ?

Thanks & Regards,
Murugesh P.

On 8/24/21, Dirk-Willem van Gulik  wrote:
> On 24 Aug 2021, at 09:47, murugesh pitchaiah 
> wrote:
>>
>> Hi,
>>
>> I am working on generating the x509v3 certificates for ssh user. I see
>> with the default_md as 'sha256', in openssl.cnf file, the
>> key/certificate is generated with algorithm type as 'x509v3-sign-rsa'.
>>
>> I see its signature algorithm is :
>>
>>Signature Algorithm: sha256WithRSAEncryption
>>Public Key Algorithm: rsaEncryption
>>Public-Key: (2048 bit)
>>
>>
>> Can any one please share how to generate certificate for
>> x509v3-ssh-rsa and x509v3-rsa2048-sha256 ? Basically looking for
>> difference between these three type of public key algorithms ,and how
>> to generate certificate of these types:
>>
>> x509v3-sign-rsa, x509v3-ssh-rsa and x509v3-rsa2048-sha256
>>
>> Because, even for x509v3-sign-rsa - I see the size is 2048 bit and it
>> is sha256. Is it something to vary in 'default_md' (or newkey rsa:size
>> and -sha) fields to vary to generate these different cert types ?
>
> Try something like
>
>   openssl req -new -x509 -newkey rsa:1024 -sha256 -keyout /dev/stdout 
> -nodes
> -subj /CN=foo  |\
>   openssl x509 -pubkey -noout | openssl rsa  -text -pubin -noout
>
>   openssl req -new -x509 -newkey rsa:1024 -sha256 -keyout /dev/stdout 
> -nodes
> -subj /CN=foo |\
>   openssl x509 -text -noout | grep Signature
>   
> And vary the newkey argument to see what it actually generates as an RSA
> key.
>
> In this example a 1024 bit one. You can also vary sha256 to things like md5,
> etc.
>
> Dw.

Re: Consultation:Additional “ephemeral public key” and “ephemeral private key" implementations for quictls/opens

[Nobuo Aoki]

Dear OpenSSL users

Thanks for thinking about it.
(Especially grateful to Mr./Ms. Mattl, Michael and Kris. )

I took a little time to clarify our questions.
The attached document is a diagram of our idea 
of how the original protocol and TLS should work together.

Objective:
We want to implement QUIC-TLS, which is lightweight and secure.
Specifically, we would like to implement a handshake protocol by incorporating 
non-standard protocols.
For example, we are considering a post-quantum key exchange protocol.
This is just a part of our research, and we are not considering a new 
standardization proposal for TLS handshaking that includes the above protocols 
at this stage.

What we would like to hear:
1. what exactly is the structure that stores ephemeral keys in ECDHE/DHE?
2. What is the function that calculates the ephemeral public key of ECDHE/DHE 
and stores the value in the above structure?
3. After receiving a client hello or server hello message, where is the part 
that extracts the ephemeral public key of the communication partner from the 
received message? Also, where is the place to calculate the session key from 
ECDHE/DHE?

Additional two information.
Current situation:
I'm trying to implement it using "msquic".
The handshake in "msquic" uses "quictls" forked from OpenSSL, but I think the 
implementation of the TLS handshake is based on OpenSSL.

Problem:
I would like to be able to use the TLS handshake part of OpenSSL (ClientHello, 
ServerHello) with protocol messages on behalf of ECDHE and DHE to perform key 
exchange and pass the generated session key to the TLS record protocol.

Nobuo Aoki (master 1st student, Japan).

(It seems that the file could not be attached because of the large sending byte 
size. Instead, I'll share it from my university's storage. Here is the link for 
sharing)
https://hunet-my.sharepoint.com/:i:/g/personal/mg66001_e_hiroshima-cu_ac_jp/Ecmdv1CofjZCniQ9vWFSLu4Bjfm7bYuShGcdG1J0IRZzjQ?e=p5s3uV
 


> 2021/08/30 16:57、Matt Caswell のメール:
> 
> 
> 
> On 29/08/2021 20:41, Nobuo Aoki wrote:
>> I am trying to identify the implementation
>> where “ephemeral public key” and “ephemeral private key” can be added,
> 
> I am unclear from your question whether you are asking how to add a new 
> public/private key scheme for integration into TLS. Or whether you are simply 
> asking for the location in the code where the key_share is generated. If the 
> latter then you might look here for the client side:
> 
> https://github.com/openssl/openssl/blob/e8e1f6d1a9e599d575431f559200018b8f822e0f/ssl/statem/extensions_clnt.c#L649-L705
> 
> And here for the server side:
> 
> https://github.com/openssl/openssl/blob/e8e1f6d1a9e599d575431f559200018b8f822e0f/ssl/statem/extensions_srvr.c#L1577-L1707
> 
> 
> Matt
> 

RE: client authentication status

[Zeke Evans]

Thanks for the explanation.  I figured I was headed down a dead end.  This will 
at least help me figure out how to handle things appropriately.

Zeke Evans

Re: client authentication status

[Matt Caswell]

On 01/09/2021 16:36, Zeke Evans wrote:
Is there any way to check the status of client authentication sent in a 
TLS 1.3 handshake after SSL_connect returns?  With TLS 1.2 SSL_connect 
seems to always capture the status and return an error code if it failed 
but not TLS 1.3.  I haven’t been able to find a good way to do this 
after SSL_connect returns.  I have to handle blocking and non-blocking 
sockets so calling SSL_read or SSL_peek isn’t an option since those 
could block.  If client authentication happened to fail then calling 
those methods would work because they will return an error but if it 
didn’t fail then they could block.


At a protocol level the handshake looks like this:

   Client   Server

Key  ^ ClientHello
Exch | + key_share*
 | + signature_algorithms*
 | + psk_key_exchange_modes*
 v + pre_shared_key*   >
  ServerHello  ^ Key
 + key_share*  | Exch
+ pre_shared_key*  v
{EncryptedExtensions}  ^  Server
{CertificateRequest*}  v  Params
   {Certificate*}  ^
 {CertificateVerify*}  | Auth
   {Finished}  v
   <  [Application Data*]
 ^ {Certificate*}
Auth | {CertificateVerify*}
 v {Finished}  >
   [Application Data]  <--->  [Application Data]


The handshake has completed from the perspective of one of the endpoints 
once it has both sent and received a "Finished" message.


From the above you can see that the client receives the server's 
"Finished" message before it sends its "Certificate"/"CertificateVerify" 
and "Finished" messages back to the server. At this point "SSL_connect" 
returns and the client is ready to start receiving application data.


From the server's perspective it is still handshaking when it receives 
the client's certificate (because it didn't receive the client's 
"Finished" message yet). So the server when send an alert at this point 
if the certificate is not acceptable and SSL_accept() will return with a 
failure.


The client does not know what it will receive back from the server. It 
could either be application data (in the case of an accepted 
certificate) or an alert (in the case of a reject certificate). The only 
way it can find out is to attempt to read data from the connection and 
see what it gets back. The API to do this is SSL_read()/SSL_peek().


So, to answer your question, there is no way to check the status of 
client authentication without calling SSL_read()/SSL_peek(). It 
necessarily requires an attempt to read data from the socket in order to 
find that status out due to the way the protocol is designed.



On 01/09/2021 16:51, Benjamin Kaduk via openssl-users wrote:
> Note that the server is allowed to ignore a client cert that it 
doesn't like, proceeding with the connection as if the client was 
unauthenticated.  If you need a specific signal that the server believes 
the client successfully authenticated, that has to be at the application 
layer.


This is true, but ultimately the client still needs to attempt to read 
data from the socket to figure out what the server did.


> Did you try a zero-length SSL_read()?  My recollection is that that 
gets far enough into the library to see if there are pending alert 
messages to process.


Again, there will only be alerts to process (related to a client 
certificate failure) if the client has attempted to read application data.


Matt

Re: client authentication status

[Benjamin Kaduk via openssl-users]

On Wed, Sep 01, 2021 at 03:36:36PM +, Zeke Evans wrote:
> Hi,
> 
> Is there any way to check the status of client authentication sent in a TLS 
> 1.3 handshake after SSL_connect returns?  With TLS 1.2 SSL_connect seems to 
> always capture the status and return an error code if it failed but not TLS 
> 1.3.  I haven't been able to find a good way to do this after SSL_connect 
> returns.  I have to handle blocking and non-blocking sockets so calling 
> SSL_read or SSL_peek isn't an option since those could block.  If client 
> authentication happened to fail then calling those methods would work because 
> they will return an error but if it didn't fail then they could block.

Note that the server is allowed to ignore a client cert that it doesn't like, 
proceeding with the connection as if the client was unauthenticated.  If you 
need a specific signal that the server believes the client successfully 
authenticated, that has to be at the application layer.

Did you try a zero-length SSL_read()?  My recollection is that that gets far 
enough into the library to see if there are pending alert messages to process.

-Ben

client authentication status

[Zeke Evans]

Hi,

Is there any way to check the status of client authentication sent in a TLS 1.3 
handshake after SSL_connect returns?  With TLS 1.2 SSL_connect seems to always 
capture the status and return an error code if it failed but not TLS 1.3.  I 
haven't been able to find a good way to do this after SSL_connect returns.  I 
have to handle blocking and non-blocking sockets so calling SSL_read or 
SSL_peek isn't an option since those could block.  If client authentication 
happened to fail then calling those methods would work because they will return 
an error but if it didn't fail then they could block.

Thanks,
Zeke Evans