Re: aes_cbc_hmac_sha1 implementation

[Matt Caswell]

On 24/02/2020 13:04, Phani 2004 wrote:
> Hi Team,
> 
> "aes_cbc_hmac_sha1" implementation is currently supported on x86
> platforms only.
> With which RFC is this compliant with?
> This cipher is only used when the "encrypt then mac" option is disabled.
> Is this understanding correct. I am using openssl s_server and s_client
> is i use the below command on client side.
> 
> openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_
> 
> Is this correct?
> I have following queries:
> 
>  1. With which RFC is the current aes_cbc_hmac_sha1 implementation
> compliant with?

Its a cipher used by AES128 and HMAC-SHA1 based ciphersuites compliant
with TLSv1.2 (RFC5246) and earlier TLS protocol versions.

>  2. It always does "mac then encrypt". Infact this cipher is invoked
> only when "encrypt then mac" flag is disabled. Is this correct?

Correct. We always try to do encrypt-then-mac by default so s_client
talking to s_server from the same OpenSSL version should never use this
ciphersuuite

>  3. Is the cipher i used in above s_client command correct?
> 

openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_

The "-tls_" on the end is incorrect - that's not a valid flag. Perhaps
you meant "-no_tls1_3" which would be fine. That's still not sufficient
to guarantee usage of the aes_cbc_hmac_sha1 cipher though because
Encrypt-then-mac will always be preferred.

I don't think there is a command line option to s_client to force that
off, although you can do it through a config file using the
"EncryptThenMac" option.

Matt


> Thanks in advance.
> 
> Regards
> Phani

Re: Problems revoking a cert

[Michael Leone]

On Mon, Feb 24, 2020 at 12:09 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Michael Leone
> > Sent: Monday, February 24, 2020 09:37
>
> > SO I was an idiot, and signed a certificate, but specified an invalid
> location. i.e.,
> > I used a "/" instead of a "/" in the location.
>
> I assume that was supposed to be 'a "\" instead of a "/"', based on what
> you have below.
>

Yes, I had it backwards. And I was able to find the file, and properly
revoke it, after sending my initial email. I just haven't had time to go
back and tell the list.


>
> > $ sudo openssl ca -in requests/.req -out
> certs\-2020-02-24.
> >
> > And so I can't find that cert file anywhere (obviously).
>
> That's not obvious at all.


I meant - obviously it's not in the subdirectory I thought it would be in
...



> Does your CA configuration not have a new_certs_dir? Normally it will
> create a copy of the certificate there, under the serial number.
>
> > I know the serial number of the wrongly issued cert, I had hoped I could
> revoke
> > using just the serial number. But searches tell me I can't do it that
> way.
>
> Well, you *can*, by editing the CA's index.txt file directly. You can
> create and revoke a test certificate to see what the altered line should
> look like. (It will start with "R" instead of "V", and have a revocation
> date. Fields are separated by tabs.)
>

Interesting. Thanks.

RE: Problems revoking a cert

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Michael Leone
> Sent: Monday, February 24, 2020 09:37

> SO I was an idiot, and signed a certificate, but specified an invalid 
> location. i.e.,
> I used a "/" instead of a "/" in the location.

I assume that was supposed to be 'a "\" instead of a "/"', based on what you 
have below.

> $ sudo openssl ca -in requests/.req -out 
> certs\-2020-02-24.
>
> And so I can't find that cert file anywhere (obviously).

That's not obvious at all. The backslash just escapes the first character of 
 for the shell (assuming root's shell isn't something very 
idiosyncratic), so the file should just be named

   certs-2020-02-4.

(substituting the appropriate strings), and should be in the directory 
containing the requests and certs directories. Since you ran openssl as root 
(which wouldn't be my choice, but whatever), write permission to the directory 
shouldn't have been a problem.

> So I'd like to revoke it, so that I can re-sign it properly. But whenever I 
> go to
> revoke it, I have nothing to use an input to the revoke functionality.

Does your CA configuration not have a new_certs_dir? Normally it will create a 
copy of the certificate there, under the serial number.

> I know the serial number of the wrongly issued cert, I had hoped I could 
> revoke
> using just the serial number. But searches tell me I can't do it that way.

Well, you *can*, by editing the CA's index.txt file directly. You can create 
and revoke a test certificate to see what the altered line should look like. 
(It will start with "R" instead of "V", and have a revocation date. Fields are 
separated by tabs.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Problems revoking a cert

[Michael Leone]

SO I was an idiot, and signed a certificate, but specified an invalid
location. i.e., I used a "/" instead of a "/" in the location.

$ sudo openssl ca -in requests/.req -out
certs\-2020-02-24.

And so I can't find that cert file anywhere (obviously). So I'd like to
revoke it, so that I can re-sign it properly. But whenever I go to revoke
it, I have nothing to use an input to the revoke functionality.

I know the serial number of the wrongly issued cert, I had hoped I could
revoke using just the serial number. But searches tell me I can't do it
that way.

So what can I do now? (short of asking for another request file, I mean - I
can't resign the existing one, openssl tells me that a cert already exists.
And I don't think I can just insert the bad cert serial number in the CRL,
right? To "effectively" revoke it, so I can resign, properly?).

Thanks
-- 

Mike. Leone, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...

aes_cbc_hmac_sha1 implementation

[Phani 2004]

Hi Team,

"aes_cbc_hmac_sha1" implementation is currently supported on x86 platforms
only.
With which RFC is this compliant with?
This cipher is only used when the "encrypt then mac" option is disabled. Is
this understanding correct. I am using openssl s_server and s_client is i
use the below command on client side.

openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_

Is this correct?
I have following queries:

   1. With which RFC is the current aes_cbc_hmac_sha1 implementation
   compliant with?
   2. It always does "mac then encrypt". Infact this cipher is invoked only
   when "encrypt then mac" flag is disabled. Is this correct?
   3. Is the cipher i used in above s_client command correct?

Thanks in advance.

Regards
Phani