Re: [openssl-users] SMIME_read_CMS and binary signature

[Viktor Dukhovni]

> On Feb 15, 2018, at 12:29 AM, e...@coderhacks.com wrote:
> 
> If I try SMIME_read_CMS it is working well if the signature (the 2nd 
> MIME-part with smime-type=singed-data)
> has a Content-Transfer-Encodeing of "base64" (as it is in my example)
> 
> But It is not working if the CTE is "binary" and also the content is.

"binary" is not valid Content-Transfer-Encoding for SMIME.

RFC 2045 Section 6.2:

   Mail transport for unencoded 8bit data is defined in RFC 1652.  As of
   the initial publication of this document, there are no standardized
   Internet mail transports for which it is legitimate to include
   unencoded binary data in mail bodies.  Thus there are no
   circumstances in which the "binary" Content-Transfer-Encoding is
   actually valid in Internet mail.  However, in the event that binary
   mail transport becomes a reality in Internet mail, or when MIME is
   used in conjunction with any other binary-capable mail transport
   mechanism, binary bodies must be labelled as such using this
   mechanism.

Even if such a binary transport existed, there is no mechanism to embed
non line-oriented data inside a line-oriented MIME multipart.

If you want binary data, use DER-encoded CMS objects not SMIME.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SMIME_read_CMS and binary signature

[e...@coderhacks.com]

Hello!

I need a little hint for parsing SMIME into a CMS_ContentInfo.

Here is an shortend example of my SMIME to make clear the structure of 
my content.




Content-Type: multipart/signed; protocol="application/pkcs7-signature"; 
micalg=sha1; boundary="=_Part_abcde"


--=_Part_abcde
Content-Type: application/text; name=abc.txt
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=abc.txt

VU...Cc=

--=_Part_abcde
Content-Type: application/pkcs7-signature; name=smime.p7s; 
smime-type=signed-data

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIA...AAA=

--=_Part_abcde--




If I try SMIME_read_CMS it is working well if the signature (the 2nd 
MIME-part with smime-type=singed-data)

has a Content-Transfer-Encodeing of "base64" (as it is in my example)

But It is not working if the CTE is "binary" and also the content is.

If I manually convert the signature to base64 and change the CTE to 
base64 the SMIME_read_CMS is working again.


Is there another way of handling that? Maybe another function?
Thanks for help!

Best regards,
Chris
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] error (openssl-1.1.0g)

[Sakuma, Koshiro]

Hi, Matt,

Yes, I did with root user, but it was failed like "access denied" when I
tried to do with normal user account.
Also, I didn't get any error messages like "root" user or something in the
log file.

Regards


2018-02-15 9:44 GMT+09:00 Matt Caswell :

> Did you run "make test" as root by any chance? There is a known issue
> where this test fails if you run it as root (fixed in git by commit
> b15e62ecc).
>
> Matt
>
> On 14/02/18 21:33, Sakuma, Koshiro wrote:
> > Hi, Team,
> >
> > I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten
> > error during do the "make test" phase.  The error I've gotten is as
> follows.
> >
> > 
> -
> > ./test/recipes/40-test_rehash.t ... Dubious, test returned 1
> > (wstat 256, 0x100)
> > Failed 1/5 subtests
> >
> > Test Summary Report
> > ---
> > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)
> >   Failed test:  4
> >   Non-zero exit status: 1
> > Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56
> > cusr  9.26 csys = 35.23 CPU)
> > Result: FAIL
> > make[1]: *** [_tests] Error 1
> > make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g
> > make[1]:***[tests] error 2
> > 
> -
> >
> > The command I tried to do was like "config --prefix=/usr/local/openssl
> > shared zlib OR config shared OR config.
> >
> > The OS version is CentOS Linux release 7.4.1708 (Core).
> >
> > I am not sure if I can ignore this error and move forward to do "make".
> >
> > Thank you so much for your support.
> >
> > Regards,
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Explicit IV in TLS 1.1+

[Curt Johansson]

Hi Matt, thanks for your prompt answer. The testclient is using openssl-1.0.2m 
and my previous assumption that the IV was derived from the key_block as in TLS 
1.0 was wrong. 
It seems that when initialising the cipher with the IV is ignored when the 
crypto is AES and the first 16 bytes of the encrypted payload is used as IV (as 
per TLS spec). This is a Java issue 
and has nothing to do with OpenSSL but assuming this is correct behaviour (I'll 
have to dig in to that) I use the same logic (in this respect) for TLS1.1 and 
TLS1.2  assuming that
the client also does which it obviously does not. 

Below is the logging from my server handling two authentications (the Finished 
message that is the first encrypted). The first (TLS1.1) succeeds and the 
second (1.2) fails. You can see that the decrypted text is correctly padded in 
the first case (TLS 1.1) indicating that the decryption succeeded but the 
second (1.2) decrypted buffer does not. The "Finished" message for this (AES; 
SHA) mac- and block size should be padded with 11 bytes which the first is. 
Also as seen I use the same provider and algoritm in the two cases, actually I 
handle the decryption in the same way for the two TLS-levels


Also added the wireshark output for the two authentications where I've verified 
that the logged encrypted data really is whats coming in on the line. 


Basically when selecting 1.1 in the client everything works as expected but 
selecting 1.2 the prepended IV is not correct as far as I understand. The 
testclient vendor says they are using
OpenSLL for TLS handling so I expect that they're not fiddling with any IV 
bytes at all. Given the version 1.0.2m, can this be explained? 


Best 
Curt 



TLS11-TLS12.pcapng
Description: Binary data


TLS 1.1
 
04:09:40.295 Cipher provider: SunJCE
04:09:40.295 Cipher algoritm: AES/CBC/NoPadding
04:09:40.295 IV from key_block used in cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0]
04:09:40.295 Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 
5f, 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f, c4, 
28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c, 89, ef, bb, 68, 
6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b]
04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73, b3, 85, 
19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35, 37, bc, 2a, 87, 79, 
78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3, 36, d, 3b, be, 4a, b, b, b, b, 
b, b, b, b, b, b, b, b]

TLS 1.2
04:09:47.779 Cipher provider: SunJCE
04:09:47.779 Cipher algoritm: AES/CBC/NoPadding
04:09:47.779 IV from key_block used in cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0]
04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d, 88, b, 4d, 
af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0, a0, 35, c5, 95, 3d, 
d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a, 57, e3, f9, 89, 3f, 83, 11, 
cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c]
04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe, 2a, 18, 
a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad, 45, f9, e3, 42, aa, 
e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca, 24, 25, 70, 7c, a9, f6, 19, 17, 
f5, ef, ee, b, 30, 2f, ec, 4d, b3, 9c, 8b]



> On 14 Feb 2018, at 0:26 , Matt Caswell  wrote:
> 
> 
> 
> On 13/02/18 22:02, Curt Johansson wrote:
>> Hi all, 
>> 
>> I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now 
>> only handles TLS 1.0. I'm testing with a testtool that the vendor says is
>> using OpenSSL to implement the TLS support. It all seems to work except for 
>> the following: 
>> 
>> When all key exchange messages are sent from the server and back from the 
>> client the client sends the "Finished" message which 
>> is the first encrypted with the negotiated symmetric cipher suite. I use 
>> AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1) 
>> the IV is prepended to the encrypted message (containing the payload, MAC 
>> and padding). The message size i right and when (in the server) I use the 
>> first 16 bytes 
>> of the message received from the client as IV the decryption fails but when 
>> I use the mechanism from TLS 1.0 to pick up the IV from 
>> the key_block the decryption is successful. I understand that this is one 
>> way to generate the IV that I suppose you use which is fine but 
>> shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted 
>> data that is sent to the server? In TLS 1.2 there is not IV material 
>> generated 
>> at all in the key_block so in that case I don't even know where to find it. 
>> 
>> The simple question is, shouldn't the first 16 bytes (assuming AES) of the 
>> message (after the 5 byte header) be the unencrypted IV to be used in the 
>> decryption of the rest of the message?
> 
> Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 or
> TLSv1.2, then that is what happens. You don't say what version of

Re: [openssl-users] error (openssl-1.1.0g)

[Matt Caswell]

Did you run "make test" as root by any chance? There is a known issue
where this test fails if you run it as root (fixed in git by commit
b15e62ecc).

Matt

On 14/02/18 21:33, Sakuma, Koshiro wrote:
> Hi, Team,
> 
> I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten
> error during do the "make test" phase.  The error I've gotten is as follows.
> 
> -
> ./test/recipes/40-test_rehash.t ... Dubious, test returned 1
> (wstat 256, 0x100)
> Failed 1/5 subtests
> 
> Test Summary Report
> ---
> ../test/recipes/40-test_rehash.t         (Wstat: 256 Tests: 5 Failed: 1)
>   Failed test:  4
>   Non-zero exit status: 1
> Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56
> cusr  9.26 csys = 35.23 CPU)
> Result: FAIL
> make[1]: *** [_tests] Error 1
> make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g
> make[1]:***[tests] error 2
> -
> 
> The command I tried to do was like "config --prefix=/usr/local/openssl
> shared zlib OR config shared OR config.
> 
> The OS version is CentOS Linux release 7.4.1708 (Core).
> 
> I am not sure if I can ignore this error and move forward to do "make". 
> 
> Thank you so much for your support.
> 
> Regards,
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] TLS 1.3 PSK test server setup

[Matt Caswell]

On 14/02/18 19:39, Hubert Kario wrote:
> How to start current master branch OpenSSL so that it will support static PSK 
> key exchange in TLS1.3?
> 
> with client running as:
> openssl s_client -psk 
> 
> 
> I've tried:
> openssl s_server -psk 
>  -nocert
> 
> that produces
> 13982311024:error:14201076:SSL routines:tls_choose_sigalg:no suitable 
> signature algorithm:ssl/t1_lib.c:2433:
> and a handshake_failure alert sent to client
> 
> and I've also tried
> openssl s_server -psk 
>  -cert 
> cert.pem -key key.pem
> (where cert and key pem are just self signed RSA cert and key)

For a PSK to be used in needs to be the correct length for the selected
ciphersuite. The ciphersuite is selected *first*. Next the available
PSKs are checked to see if they are usable with that ciphersuite.

By default s_client talking to s_server will select
TLS13-AES-256-GCM-SHA384. Because this is based on SHA384 we need a key
which is 48 bytes long (96 hex digits). Your key is 32 bytes long (64
hex digits) so the PSK is ignored.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] error (openssl-1.1.0g)

[Salz, Rich via openssl-users]

For the failing test, try this
make TESTS=test_rehash V=1 tests

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] error (openssl-1.1.0g)

[Blumenthal, Uri - 0553 - MITLL]

Thanks for your feedback.  

 

You’re welcome.

 

You think it might be something like "BUG"??  

 

Probably yes – but the question is whether it’s with the new OpenSSL test 
infrastructure, or something with how one of my machines is configured. I do 
not know.

 

Anyway, you are also waiting for the answers right?

 

Yes I certainly am.

 

2018-02-15 6:57 GMT+09:00 Blumenthal, Uri - 0553 - MITLL :

Funny. I have the same problem with the current master on one of my two MacOS 
High Sierra machines. Surprisingly, the other machine builds and runs the 
current master just fine. Configuration and build scripts are automated and 
exactly the same between the two. 

 

The “bad” machine runs a bunch of compliance-related software, but it did not 
seem to interfere with the previous OpenSSL code drops.

--

Regards,

Uri Blumenthal

From: openssl-users  on behalf of "Sakuma, 
Koshiro" 
Reply-To: "openssl-users@openssl.org" 
Date: Wednesday, February 14, 2018 at 16:33
To: "openssl-users@openssl.org" 
Subject: [openssl-users] error (openssl-1.1.0g)

 

Hi, Team, 

 

I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error 
during do the "make test" phase.  The error I've gotten is as follows.

 

-

./test/recipes/40-test_rehash.t ... Dubious, test returned 1 (wstat 
256, 0x100)

Failed 1/5 subtests

 

Test Summary Report

---

../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56 cusr  9.26 
csys = 35.23 CPU)

Result: FAIL

make[1]: *** [_tests] Error 1

make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g

make[1]:***[tests] error 2

-

 

The command I tried to do was like "config --prefix=/usr/local/openssl shared 
zlib OR config shared OR config.

 

The OS version is CentOS Linux release 7.4.1708 (Core).

 

I am not sure if I can ignore this error and move forward to do "make". 

 

Thank you so much for your support.

 

Regards,

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] error (openssl-1.1.0g)

[Sakuma, Koshiro]

Hi, Uri,

Thanks for your feedback.  You think it might be something like "BUG"??
Anyway, you are also waiting for the answers right?

Regards,

2018-02-15 6:57 GMT+09:00 Blumenthal, Uri - 0553 - MITLL :

> Funny. I have the same problem with the current master on one of my two
> MacOS High Sierra machines. Surprisingly, the other machine builds and runs
> the current master just fine. Configuration and build scripts are automated
> and exactly the same between the two.
>
>
>
> The “bad” machine runs a bunch of compliance-related software, but it did
> not seem to interfere with the previous OpenSSL code drops.
>
> --
>
> Regards,
>
> Uri Blumenthal
>
> *From: *openssl-users  on behalf of
> "Sakuma, Koshiro" 
> *Reply-To: *"openssl-users@openssl.org" 
> *Date: *Wednesday, February 14, 2018 at 16:33
> *To: *"openssl-users@openssl.org" 
> *Subject: *[openssl-users] error (openssl-1.1.0g)
>
>
>
> Hi, Team,
>
>
>
> I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error
> during do the "make test" phase.  The error I've gotten is as follows.
>
>
>
> 
> -
>
> ./test/recipes/40-test_rehash.t ... Dubious, test returned 1
> (wstat 256, 0x100)
>
> Failed 1/5 subtests
>
>
>
> Test Summary Report
>
> ---
>
> ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)
>
>   Failed test:  4
>
>   Non-zero exit status: 1
>
> Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56 cusr
> 9.26 csys = 35.23 CPU)
>
> Result: FAIL
>
> make[1]: *** [_tests] Error 1
>
> make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g
>
> make[1]:***[tests] error 2
>
> 
> -
>
>
>
> The command I tried to do was like "config --prefix=/usr/local/openssl
> shared zlib OR config shared OR config.
>
>
>
> The OS version is CentOS Linux release 7.4.1708 (Core).
>
>
>
> I am not sure if I can ignore this error and move forward to do "make".
>
>
>
> Thank you so much for your support.
>
>
>
> Regards,
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] error (openssl-1.1.0g)

[Blumenthal, Uri - 0553 - MITLL]

Funny. I have the same problem with the current master on one of my two MacOS 
High Sierra machines. Surprisingly, the other machine builds and runs the 
current master just fine. Configuration and build scripts are automated and 
exactly the same between the two. 

 

The “bad” machine runs a bunch of compliance-related software, but it did not 
seem to interfere with the previous OpenSSL code drops.

--

Regards,

Uri Blumenthal

From: openssl-users  on behalf of "Sakuma, 
Koshiro" 
Reply-To: "openssl-users@openssl.org" 
Date: Wednesday, February 14, 2018 at 16:33
To: "openssl-users@openssl.org" 
Subject: [openssl-users] error (openssl-1.1.0g)

 

Hi, Team, 

 

I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error 
during do the "make test" phase.  The error I've gotten is as follows.

 

-

./test/recipes/40-test_rehash.t ... Dubious, test returned 1 (wstat 
256, 0x100)

Failed 1/5 subtests

 

Test Summary Report

---

../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56 cusr  9.26 
csys = 35.23 CPU)

Result: FAIL

make[1]: *** [_tests] Error 1

make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g

make[1]:***[tests] error 2

-

 

The command I tried to do was like "config --prefix=/usr/local/openssl shared 
zlib OR config shared OR config.

 

The OS version is CentOS Linux release 7.4.1708 (Core).

 

I am not sure if I can ignore this error and move forward to do "make". 

 

Thank you so much for your support.

 

Regards,

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] error (openssl-1.1.0g)

[Sakuma, Koshiro]

 Hi, Team,

I'm trying to install openssl-1.1.0g on my CentOS7, but I've gotten error
during do the "make test" phase.  The error I've gotten is as follows.


-
./test/recipes/40-test_rehash.t ... Dubious, test returned 1 (wstat
256, 0x100)
Failed 1/5 subtests

Test Summary Report
---
../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=95, Tests=554, 34 wallclock secs ( 0.32 usr  0.09 sys + 25.56 cusr
9.26 csys = 35.23 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make[1]: Leaving directory `/usr/local/src/openssl-1.1.0g
make[1]:***[tests] error 2

-

The command I tried to do was like "config --prefix=/usr/local/openssl
shared zlib OR config shared OR config.

The OS version is CentOS Linux release 7.4.1708 (Core).

I am not sure if I can ignore this error and move forward to do "make".

Thank you so much for your support.

Regards,
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] TLS 1.3 PSK test server setup

[Hubert Kario]

How to start current master branch OpenSSL so that it will support static PSK 
key exchange in TLS1.3?

with client running as:
openssl s_client -psk 


I've tried:
openssl s_server -psk 
 -nocert

that produces
13982311024:error:14201076:SSL routines:tls_choose_sigalg:no suitable 
signature algorithm:ssl/t1_lib.c:2433:
and a handshake_failure alert sent to client

and I've also tried
openssl s_server -psk 
 -cert 
cert.pem -key key.pem
(where cert and key pem are just self signed RSA cert and key)

that establishes a TLS1.3 connection, but the ServerHello does not include 
pre_shared_key extension, just 43 (selected version) and 51 (key share), so 
the PSK mode was not used

connecting with s_client -tls1_2 a PSK cipher is selected (DHE-PSK-AES256-GCM-
SHA384) and in TLS1.3 I see both the pre_shared_key extension and the 
psk_key_exchange_modes extension in client hello, so I'm really confused why 
it doesn't work.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl 1.1 / TLS 1.3

[Richard Moore]

On 14 February 2018 at 16:34, Matt Caswell  wrote:

>
>
> On 14/02/18 16:27, Richard Moore wrote:
> > If I run the following:
> >
> >  openssl-1.1.1pre1 ciphers -tls1_3 -v
>
> The man page says this about the "-tls1_3" option:
>
> "In combination with the B<-s> option, list the ciphers which would be
> used if TLSv1.3 were negotiated."
>
> So you need to add "-s". If you do that then you only get the TLSv1.3
> ciphers. It's a little strange that the option is ignored if no -s is
> supplied (you might think supplying -tls1_3 would automatically imply
> -s). But that is the way that all the -tls* options work, so this is
> nothing new in 1.1.1.
>

​I see thanks. That's very confusing, but yeah it seems to be there since
1.1.0. How would you feel about that being the default? I'm a little bit
unclear about what the point of the option is otherwise?

Thanks

Rich.
​
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl 1.1 / TLS 1.3

[Matt Caswell]

On 14/02/18 16:27, Richard Moore wrote:
> If I run the following:
> 
>  openssl-1.1.1pre1 ciphers -tls1_3 -v

The man page says this about the "-tls1_3" option:

"In combination with the B<-s> option, list the ciphers which would be
used if TLSv1.3 were negotiated."

So you need to add "-s". If you do that then you only get the TLSv1.3
ciphers. It's a little strange that the option is ignored if no -s is
supplied (you might think supplying -tls1_3 would automatically imply
-s). But that is the way that all the -tls* options work, so this is
nothing new in 1.1.1.

Matt



> 
> Then I get lots of ciphers, for example AES128-SHA however the latest
> draft TLS 1.3 RFC states:
> 
> The list of supported symmetric algorithms has been pruned of all
> algorithms that are considered legacy. Those that remain all use
> Authenticated Encryption with Associated Data (AEAD) algorithms.
> 
> This suggests that the ciphers command isn't working as intended. Should
> I file an issue in github?
> 
> Cheers
> 
> Rich.
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Openssl 1.1 / TLS 1.3

[Richard Moore]

If I run the following:

 openssl-1.1.1pre1 ciphers -tls1_3 -v

Then I get lots of ciphers, for example AES128-SHA however the latest draft
TLS 1.3 RFC states:

The list of supported symmetric algorithms has been pruned of all
algorithms that are considered legacy. Those that remain all use
Authenticated Encryption with Associated Data (AEAD) algorithms.

This suggests that the ciphers command isn't working as intended. Should I
file an issue in github?

Cheers

Rich.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OSSL_STORE_ctrl

[Richard Levitte]

In message  on Tue, 13 
Feb 2018 19:58:34 -0800, Norm Green  said:

norm.green> In 1.1.1 pre-relase 1, we have this new function:
norm.green> 
norm.green> int OSSL_STORE_ctrl(OSSL_STORE_CTX *ctx, int cmd, ... /* args */);
norm.green> 
norm.green> Would it be possible to add a version that takes va_args like this?
norm.green> 
norm.green> int OSSL_STORE_vctrl(OSSL_STORE_CTX *ctx, int cmd, va_list args);
norm.green> 
norm.green> OpenSSL already have this precedent in other places, such as with
norm.green> BIO_printf() / BIO_vprintf()

Good idea, that can certainly be done.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users