OpenSSL 1.1.1 (full support) expires 2022-09-11, any plans for a full bug fix release?

[Short, Todd via openssl-users]

OpenSSL 1.1.1 full support expires on 2022-09-11; it then enters 
security-fix-only mode until 2023-09-11.

Are there any plans for a final bug-fix release of 1.1.1 in the next couple 
weeks (and hopefully a 3.0 release as well)?

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."



signature.asc
Description: Message signed with OpenPGP

Re: OpenSSL 3.0 LTS

[Short, Todd via openssl-users]

Apple uses LibreSSL, not OpenSSL, in their recent OSes:

~$ openssl version -a
LibreSSL 2.8.3
built on: date not available
platform: information not available
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: information not available
OPENSSLDIR: "/private/etc/ssl"
~$ uname -mprsv
Darwin 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; 
root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64 i386
~$

--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."

> On Mar 4, 2022, at 9:26 AM, The Doctor via openssl-users 
>  wrote:
> 
> On Fri, Mar 04, 2022 at 11:04:00AM +, Matt Caswell wrote:
>> OpenSSL 3.0 has recently been designated as a Long Term Support (LTS)
>> release. This means that it will now be supported until 7th September
>> 2026 (5 years after its initial release).
>> 
>> Our previous LTS release (1.1.1) will continue to be supported until
>> 11th September 2023.
>> 
>> We encourage all users to upgrade to 3.0.
>> 
> 
> 
> Though I full agree, what is Apple's stand on gettng their clients upgraded
> to openssl3 compilance?
> 
>> Yours,
>> The OpenSSL Project Team
> 
> 
> 
> 
> 
> 
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
> doctor@@nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist 
> rising!
> Look at Psalms 14 and 53 on Atheism 
> https://urldefense.com/v3/__https://www.empire.kred/ROOTNK?t=94a1f39b__;!!GjvTz_vk!D9V7BUjD7_WYZb-MFNIM1B5vPCGGhjFNF3Bh8w6c_691AQgafZRZJZmvQfcb$
> Siding with murders against the innocent is progress only to fools. -unknown 
> Beware 
> https://urldefense.com/v3/__https://mindspring.com__;!!GjvTz_vk!D9V7BUjD7_WYZb-MFNIM1B5vPCGGhjFNF3Bh8w6c_691AQgafZRZJRTcE69B$



signature.asc
Description: Message signed with OpenPGP

Time for OpenSSL 1.1.1l?

[Short, Todd via openssl-users]

The cadence of 1.1.1 release is supposed to be quarterly (I seem to recall 
reading that somewhere, but I can't find it)?

It has been almost 4 months since 1.1.1k (25-March-2021) was released.

Are there any plans for 1.1.1l (ell)?

--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."



signature.asc
Description: Message signed with OpenPGP

Re: Serialize/Deserialize SSL state

[Short, Todd via openssl-users]

Not without a lot of work. It’s not part of the current API.

We have tried doing an internal implementation; it was over 1K of new code, and 
it wasn’t complete.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, threeif by the Internet."

> On Aug 9, 2019, at 3:42 PM, Osama Mazahir via openssl-users 
>  wrote:
> 
> Is there a way to serialize and deserialize the ssl_st state (i.e. including 
> any child objects)?
>  
> Background: I would like to handoff all the SSL state (along my own managed 
> state, file descriptors, etc) to another Linux running process (I will handle 
> the IPC handoff).  The connection already had its handshake completed, app 
> data flow had already occurred (i.e. it is not a new or early’ish context).  
> So, trying to see if it is possible to serialize the openssl state, shove it 
> through a unix domain socket to the target process and then have the target 
> process unpack the openssl state and resume IO.



smime.p7s
Description: S/MIME cryptographic signature

SSL_check_chain() broken

[Short, Todd via openssl-users]

Hi,

It looks as though SSL_check_chain() use within the cert_cb (as recommended) 
was broken by PR 7257.

PR 7257 moves setting the shared_sigalgs to after the cert_cb takes place, but 
deep down in the call stack, SSL_check_chain() has a dependency on 
shared_sigalgs being set.

In 1.1.1, the following works, using SSL_check_chain() in the cert_cb. But it 
fails in 1.1.1a:

apps/openssl s_server -xcert apps/server.pem -xkey apps/server.pem -nocert

Is there harm in setting the shared_sigalgs before cert_cb and resetting them 
if SSL_set_SSL_CTX() is called? Basically what PR 7256 tried to do?

I opened issue 9099.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, threeif by the Internet."



smime.p7s
Description: S/MIME cryptographic signature

Re: AES-cipher offload to engine in openssl-fips

[Short, Todd via openssl-users]

No. 

The OpenSSL FIPS Module is not written that way. It should not be permitting 
any non-FIPS implementations (see Rich's email regarding a bug).

You could write your own engine, get that FIPS certified, and run it with 
plain, vanilla OpenSSL.

There's a design spec out for OpenSSL 3.0.0 that may allow you to have your own 
FIPS provider, which, I believe, would be the closest thing to what you want. 

--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


> On Feb 27, 2019, at 6:45 AM, suji  wrote:
> 
> Thanks for the reply.
> 
> With non-fips openssl, it is possible to write my own fips-module. I
> understood. 
> 
> But, is it possible for me to write a fips-compliant/fips validated "dynamic
> engine" with openssl-fips? Which allows me to offload "fips-compilant"
> functions to my engine "dynamically"? 
> 
> 
> 
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: Stitched vs non-Stitched Ciphersuites

[Short, Todd via openssl-users]

Thanks Matt,

So, just the cipher+MAC matter, the authentication/key-exchange are irrelevant.

What about AEAD ciphers? Are they considered "stitched"?

--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Feb 26, 2019, at 10:40 AM, Matt Caswell 
mailto:m...@openssl.org>> wrote:



On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
The latest security advisory:

https://www.openssl.org/news/secadv/20190226.txt

mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate on
which ciphersuites are stitched and non-stitched.

The actual list in use is platform specific - the stitched ciphers are based on
asm implementations. Libssl in 1.0.2 knows about these stitched ciphers:

https://github.com/openssl/openssl/blob/56ff0f643482b19f7b2d7ed532dfb94ed3a4e294/ssl/ssl_ciph.c#L651-L671

Any TLS ciphersuite based on the above ciphers will use the stitched
implementation if it is available on that platform.

So, for example, if a stitched implementation of AES-128-CBC-HMAC-SHA1 is
available on your platform then it will be used if you negotiate the AES128-SHA
ciphersuite (aka TLS_RSA_WITH_AES_128_CBC_SHA). Similarly it will be used if you
negotiate DH-RSA-AES128-SHA (aka TLS_DH_RSA_WITH_AES_128_CBC_SHA) The combined
encrypt and mac operation will be performed in one go by the stitched
implementation. If you don't have a stitched implementation then the encrypt and
mac operations are performed individually.

Matt



"In order for this to be exploitable "non-stitched" ciphersuites must be in
use. Stitched ciphersuites are optimised implementations of certain commonly
used ciphersuites."

Can someone give some examples of both?

--
-Todd Short
// tsh...@akamai.com <mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

Stitched vs non-Stitched Ciphersuites

[Short, Todd via openssl-users]

The latest security advisory:

https://www.openssl.org/news/secadv/20190226.txt

mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate 
on which ciphersuites are stitched and non-stitched.

"In order for this to be exploitable "non-stitched" ciphersuites must be in 
use. Stitched ciphersuites are optimised implementations of certain commonly 
used ciphersuites."

Can someone give some examples of both?

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

Re: [openssl-users] Extracting decrypt key for AES from openssl on client side

[Short, Todd via openssl-users]

I have seen this done for hardware acceleration; where the crypto chip can do 
everything except the handshake.
(In fact, this mechanism protected at least one device that I know of from the 
Heartbleed debacle, since the hardware crypto did not understand the record 
type.)

Look at how the kernel handles TLS, and how the keys are extracted from OpenSSL:

https://github.com/torvalds/linux/blob/master/Documentation/networking/tls.txt
https://github.com/openssl/openssl/pull/5253

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Nov 14, 2018, at 11:28 AM, Viktor Dukhovni 
mailto:openssl-us...@dukhovni.org>> wrote:



On Nov 14, 2018, at 6:54 AM, Hemant Ranvir 
mailto:hemantran...@gmail.com>> wrote:

My main goal here is to use openssl for initial handshake sequence. Once the 
connection is established between server and client, decrypt the incoming 
message (this time not using the openssl api but rather by using the decrypt 
AES function implemented earlier)

This makes no sense, because TLS does not just emit a simple CBC encrypted 
stream
after performing the handshake.  So you can't do that.  Use 
SSL_read()/SSL_write,
and let the library do the message decryption/encryption for you.  When done use
SSL_shutdown() to cleanly terminate the stream, and depending on the application
protocol, make wait for the peer's SSL_shutdown() in turn to avoid truncation
attacks where completion of the stream is not implied by the higher level 
protocol.

--
Viktor.

--
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] How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

[Short, Todd via openssl-users]

Could that be LibreSSL? (Or some similar wrapper for OpenSSL?)

https://github.com/Ruzzz/LibreSSL

This above repo creates libraries in the named format below; to match how 
Microsoft provides multiple versions of libraries.

Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not 
sure what MD stands for.

Also:
https://gitlab.kitware.com/cmake/cmake/commit/ed1758f8eb58a4e52acf0f3885f82403814f5ffd


--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 2, 2018, at 11:59 AM, Richard Levitte 
mailto:levi...@openssl.org>> wrote:

Our scripts have *never*, as far as I know, produced libraries named
like that.  Don't those DLLs come from some specific packager that
produces binary install kits?

For 1.1.x, *our* naming is a bit more elaborate, you will see these
names:

   libcrypto-1_1.dll & libssl-1_1.dll   - VC-WIN32 build
   libcrypto-1_1-x64.dll & libssl-1_1-x64.dll   - VC-WIN64A build
   libcrypto-1_1-ia64.dll & libssl-1_1-ia64.dll - VC-WIN64I build

You will also see the corresponding import libraries: libcrypto.lib &
libssl.lib

Cheers,
Richard

In message 
mailto:byapr17mb2150827bb4432c4b7edaf69ddf...@byapr17mb2150.namprd17.prod.outlook.com>>
 on Mon, 1 Oct 2018 16:29:15 +, 
mailto:aaron.frie...@non.keysight.com>> said:

A current project using Net-SNMP and OpenSSL require that these both are built 
locally (customer
requirement).

I am attempting to build OpenSSL 1.1.1.

After building OpenSSL, “nmake test” succeeds.

However, the Net-SNMP build is looking for various .lib files that are in the 
pre-built package, but
do not seem to be in what I build locally.

From the pre-built package, in the lib/VC folder:

libcrypto64MD.lib

libcrypto64MDd.lib

libcrypto64MT.lib

libcrypto64MTd.lib

libssl64MD.lib

libssl64MDd.lib

libssl64MT.lib

libssl64MTd.lib

But the VC folder is not part of my locally built version.

What am I missing in order to get these .lib files to build locally?

Thank you for your assistance.

Best Regards,
Aaron Friesen

Contract Software Engineer of Aerotek on behalf of Keysight

Keysight Technologies, Inc.

970.679.5632 T

--
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] Re-enable 3DES on NGINX + OpenSSL 1.1.1

[Short, Todd via openssl-users]

3DES is considered to only be 112 bits in strength. The default security level 
is 1 (which allows most things), perhaps nginx resets the security level to 3 
or greater (which means a minimum of 128-bit ciphers).

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Sep 17, 2018, at 4:20 PM, Neil Craig 
mailto:neil.cr...@bbc.co.uk>> wrote:

Thanks very much Matt. I have indeed built with NGINX configure opt
--with-openssl-opt=enable-weak-ssl-cipher and whilst I don¹t see an error
when running NGINX with a/some 3DES cipher(s) in the ciphers list, I don¹t
see any 3DES ciphers in the output of e.g. Testssl and I can¹t make a
connection to the server using openssl CLI with -cipher <3DES cipher>.

I wonder if the problem might be either NGINX not respecting/processing
the configure opt (above) or possibly removing 3DES ciphers for some
reason with openssl 1.1.1.

I¹ll keep digging, thanks again for your help and for confirming that¹s
the right thing to do.

Cheers

Neil Craig
Lead Technical Architect | Online Technology Group

Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org





On 17/09/2018, 17:41, "openssl-users on behalf of Matt Caswell"
mailto:openssl-users-boun...@openssl.org> on 
behalf of m...@openssl.org> wrote:



On 17/09/18 16:29, Neil Craig wrote:
Hi all

I'm trying to re-add 3DES support (a temporary move, due to business
requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX
build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt
from https://www.openssl.org/blog/blog/2016/08/24/sweet32/.

Whilst I do see some older ciphersuites being offered by NGINX after
doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was
expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but
that didn¹t work. I have also tried adding @seclevel=0 to the
ciphersuite string in NGINX but again, that didn¹t work, I don¹t see any
3DES ciphersuites available in NGINX.

I'm wondering whether something changed between the above article and
the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was
completely removed in OpenSSL 1.1.1).

Any pointers would be very much appreciated, I can¹t find anything very
useful on the web.

3DES is still available in 1.1.1 but is no longer in the DEFAULT
ciphersuite list, so unless you explicitly configure them to be
available you won't see them (even if you configure with
enable-weak-ssl-ciphers).

E.g. (assuming you compiled with enable-weak-ssl-ciphers):


$ openssl ciphers -v | grep 3DES

Will give you 0 ciphers, but

$ openssl ciphers -v 3DES | grep 3DES

Should list 14 different 3DES ciphersuites that are available.

I don't know about nginx config though so maybe someone else can help
there.

Matt

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



-
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless 
specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-
--
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] QNX 6.5 OpenSSL Build

[Short, Todd via openssl-users]

You can add the "no-dso" option to the command line to avoid this feature, but 
you lose access to loading engines.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Sep 16, 2018, at 1:04 PM, Viktor Dukhovni 
mailto:openssl-us...@dukhovni.org>> wrote:



On Sep 16, 2018, at 11:44 AM, Murugaiyan Perumal via openssl-users 
mailto:openssl-users@openssl.org>> wrote:

dso_dlfcn.c:84:12: fatal error: dlfcn.h: No such file or directory
#  include 

http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/d/dlopen.html

This header is expected to be present, perhaps your system is missing
the requisite software development package, or GCC-specific headers.

--
Viktor.

--
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] Problems with man page code example at EVP_EncryptInit

[Short, Todd via openssl-users]

PRs on GitHub to fix documentation are always welcome.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Sep 5, 2018, at 10:18 AM, Sam Habiel 
mailto:sam.hab...@gmail.com>> wrote:

I had to double check something--I was wrong about something--&outlen
is not incremented inside of openssl--so you have to keep another
variable to which you add outlen and use that to set the read/write
pointer in outbuf.

--Sam
On Wed, Sep 5, 2018 at 10:04 AM Sam Habiel 
mailto:sam.hab...@gmail.com>> wrote:

First time poster. I hope I am writing to the right place.

Example for "General encryption and decryption function example using
FILE I/O and AES128 with a 128-bit key" has two errors. I spent a lot
of time trying to figure out what I did wrong for a while...

1. ctx is already a pointer; it does not need to be indirected to get
the pointer.

   EVP_CipherInit_ex(&ctx, EVP_aes_128_cbc(), NULL, NULL, NULL,
do_encrypt);

should say:

   EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt);

2. ciphertext length is not used to update write position:

   if(!EVP_CipherUpdate(ctx, outbuf, &outlen, inbuf, inlen))
and

   if(!EVP_CipherFinal_ex(ctx, outbuf, &outlen))

should say (what worked for me):

   if(!EVP_CipherUpdate(ctx, outbuf + outlen, &outlen,
inbuf, inlen))

and
   if(!EVP_CipherFinal_ex(ctx, outbuf + outlen, &outlen))

It would be nice if there is a complete example that compiles and has
a main() to run it.

--Sam
--
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] Regarding Openssl 1.0.2p bn changes

[Short, Todd via openssl-users]

https://github.com/openssl/openssl/commit/327b2c01
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 24, 2018, at 12:18 AM, Manish Patidar 
mailto:mann.pati...@gmail.com>> wrote:

Hi,

I have doubt regarding the bn change in Openssl version 1.0.2p.

There is new flag introduced BN_FLG_FIXED_TOP,   value of this flag is zero 
untill BN_DEBUG  is defined. By default BN_DEBUG is not defined.  So what is 
the purpose of this flag.?

Regards
Mwnish
--
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] Backup of existing ssl connection

[Short, Todd via openssl-users]

Agreed, Iooked at this when creating a failover service, and trying to 
replicate all the TCP and TLS data ended up using significant CPU processing 
and network bandwidth that it wasn’t worth it; in addition to intrusive OpenSSL 
changes.

You should try to have a way to detect and re-establish a failed connection; 
it’s significantly easier to do, and requires no modification of the OpenSSL 
code. Alternatively, having two simultaneous connections might work out.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 23, 2018, at 8:36 AM, Salz, Rich via openssl-users 
mailto:openssl-users@openssl.org>> wrote:

>I want to take backup of existing ssl connection. Use this backup connection 
>in other slave board. This  backup include keys and sequence no, ssl version 
>etc.
>Is Openssl support any api to take backup of existing ssl connection?

No.  This is not currently possible, and is unlikely to ever happen in OpenSSL. 
 It’s too hard.
--
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] TLS-Session

[Short, Todd via openssl-users]

TCP Nagle + TCP Delayed ACKs can cause what appears to be the ClientHello being 
retransmitted.

Tweaking these TCP options will give you better initialization performance.

TCP_NODELAY
TCP_QUICKACK

This may not help the "end session" issue.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 20, 2018, at 9:39 AM, Viktor Dukhovni 
mailto:openssl-us...@dukhovni.org>> wrote:



On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas 
mailto:ece8...@upnet.gr>> wrote:

So my dpdk application is responding with the correct TLS alert and it actually 
block the TLS session.I have seen the correct packet in wireshark as well.I am 
also putting a picture with this mail in order to see the process.

The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS 
session.Also i am getting some retransmits of client hello in wireshark.

Re-transmission is a feature of the kernel TCP stack, and OpenSSL
has no control over this behaviour.

So my question is if anyone can confirm that this is a problem of openssl or if 
not maybe something else.
In addition if anyone know how much time does TLS session takes to actually end?

This *cannot* be an OpenSSL issue.  Your DPI firewall must not be
sending an ACK for the client HELLO payload.  Or is otherwise
failing to conform to TCP in a way that triggers re-transmission.

--
Viktor.

--
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] About 1.0.2p version release !!

[Short, Todd via openssl-users]

That site can’t be reached… (at least by me, unless it requires TLSv1.3…)

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


From: Dennis Clarke 
Reply-To: "openssl-users@openssl.org" 
Date: Friday, August 10, 2018 at 11:40 PM
To: "openssl-users@openssl.org" 
Subject: Re: [openssl-users] About 1.0.2p version release !!

On 08/10/2018 08:27 PM, Short, Todd via openssl-users wrote:
RFC 8446 (TLS 1.3) was just published about ~30 minutes ago.

Wonderful !

Todd are you okay[1] with your name being here :

 https://www.tls13.net/


Given that your name is in the maillist I figured .. sure, most likely
  .. but it is best to ask.


Dennis

--
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] About 1.0.2p version release !!

[Short, Todd via openssl-users]

RFC 8446 (TLS 1.3) was just published about ~30 minutes ago. 

--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


> On Aug 8, 2018, at 4:22 PM, Matt Caswell  wrote:
> 
> 
> 
>> On 08/08/18 21:15, The Doctor wrote:
>>> On Wed, Aug 08, 2018 at 01:46:54PM +0100, Matt Caswell wrote:
>>> 
>>> 
 On 08/08/18 13:39, The Doctor wrote:
> On Wed, Aug 08, 2018 at 09:27:43AM +0100, Matt Caswell wrote:
> 
> 
>> On 08/08/18 04:31, Juan Isoza wrote:
>> and final 1.1.1
> 
> There is no date yet. We are still waiting on the official publication
> of the TLSv1.3 RFC which we anticipate happening any day now. Once that
> happens there will be another 1.1.1 beta release cycle soon after.
> Assuming no major issues are identified in that beta the final release
> should happen soon after that.
> 
> Matt
> 
 
 MAtt how compatible is 1.1.1 to 1.1.0 brach?
 
 Will applicaions like NAmed, Exim, clamav, INND, proftpd, pure-ftpd,
 and apache et al work?
>>> 
>>> Well, I've not tested those applications but the intention is that it
>>> should be a drop in replacement and fully API/ABI compatible. However
>>> there are some potential "gotcha's" with TLSv1.3 which could cause some
>>> problems for some applications. This is primarily because the TLSv1.3
>>> protocol is significantly different to TLSv1.2 and below. See:
>>> 
>>> https://wiki.openssl.org/index.php/TLS1.3
>>> 
>>> Matt
>>> 
>> 
>> Right when will TLSv1.3 be officially recognised?
> 
> Like I said above we anticipate the RFC publication happening any day
> now. I am hopeful it could happen this week.
> 
> Matt
> 
>> 
>>> 
 
> 
>> 
>> 1.0.2p is for 14 august
>> 
>> Le??lun. 6 ao??t 2018 15:00, Hareesh D > > a ??crit??:
>> 
>>Hi,
>> 
>>Anyone know when is the official release of 1.0.2p version? Is it
>>possible to get such info about openssl version plan ?
>> 
>>Thanks !!
>>-- 
>>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
 
>>> -- 
>>> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Packet capture SSL traffic

[Short, Todd via openssl-users]

wireshark.org; it will decode it for you as well.

EKR used to have a utility on this website, but it’s likely out of date. 
Wireshark has been more frequently updated.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jul 5, 2018, at 2:20 PM, Kaushal Shriyan 
mailto:kaushalshri...@gmail.com>> wrote:

Hi,

Is there a way to capture SSL traffic using openssl and tcpdump or any other 
utility on Linux? I look forward to hearing from you.

Best Regards,

Kaushal

--
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 compiling openssh with openssl

[Short, Todd via openssl-users]

You will need to patch OpenSSH to not call the SHA256_XXX() APIs directly. To 
work with FIPS enabled, the EVP API must be used for all crypto operations.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jun 11, 2018, at 10:44 AM, Sandeep Deshpande 
mailto:sandeep@gmail.com>> wrote:

Thanks for the reply. Our appliance is enabled in FIPS mode by default.
All these days, we were using openssh 6.2 with openssl 0.9.8.
Now we need to upgrade openssl to 1.0.2j.
But we would not like to upgrade openssh at this time.

So is there is any other way we can still make it work without disabling FIPS 
mode ?

Thanks,
Sandeep

On Sat, Jun 9, 2018 at 10:38 AM, Viktor Dukhovni 
mailto:openssl-us...@dukhovni.org>> wrote:


> On Jun 9, 2018, at 1:35 PM, Sandeep Deshpande 
> mailto:sandeep@gmail.com>> wrote:
>
> We have compiled and built older version (6.2p2) of openssh with 1.0.2j 
> version of openssl.
> When the system in is crypto mode, we are getting the following error when a 
> user logs in :
> "
> OpenSSL internal error, assertion failed: Low level API call to digest SHA256 
> forbidden in FIPS mode "
>
> How do we overcome this without having to upgrade openssh ?

Don't enable FIPS mode.

--
Viktor.

--
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

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

[openssl-users] Fwd: [openssl-dev] QUIC

[Short, Todd via openssl-users]

FYI:

Matt Caswell realized how critical TLSv1.3 (and subsequently OpenSSL) is to 
QUIC.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

Begin forwarded message:

From: Benjamin Kaduk via openssl-dev 
mailto:openssl-...@openssl.org>>
Subject: Re: [openssl-dev] QUIC
Date: September 7, 2017 at 12:45:11 PM EDT
To: openssl-...@openssl.org, Matt Caswell 
mailto:m...@openssl.org>>
Reply-To: Benjamin Kaduk mailto:bka...@akamai.com>>, 
mailto:openssl-...@openssl.org>>

On 09/06/2017 05:24 PM, Matt Caswell wrote:

Issue 4283 
(https://github.com/openssl/openssl/issues/4283)
 has caused
me to take a close look at QUIC. This seems to have been getting a *lot*
of attention just recently. See the IDs below for details:


Yes, it's generated a lot of excitement and interest at the IETF.


https://tools.ietf.org/html/draft-ietf-quic-transport-05
https://tools.ietf.org/html/draft-ietf-quic-tls-05
https://tools.ietf.org/html/draft-ietf-quic-recovery-05

For the uninitiated QUIC is a new general-purpose transport protocol
built on top of UDP. It provides applications with a secure stream
abstraction (like TLS over TCP) with reliable, in-order delivery, as
well as the ability to multiplex many streams over a single connection
(without head-of-line blocking).

It is *very* closely integrated with TLSv1.3. It uses the TLSv1.3
handshake for agreeing various QUIC parameters (via extensions) as well
as for agreeing keying material and providing an "early data"
capability. The actual packet protection is done by QUIC itself (so it
doesn't use TLS application data) using a QUIC ciphersuite that matches
the negotiated TLS ciphersuite. Effectively you can think of QUIC as a
modernised rival to TLS over TCP.


The nature of the QUIC/TLSv1.3 integration is somewhat interesting.  QUIC has 
its origins at Google, and the "Google QUIC" or gQUIC variant is deployed on 
the public internet even now; since TLS 1.3 was not available then, it uses a 
separate "quic-crypto" scheme for these purposes.  quic-crypto, in turn, helped 
shape the evolution of TLS 1.3, including the strong desire for 0-RTT 
functionality.

But, as I understand it, the intent is to leave enough hooks that a different 
crypto layer could be used, including (but not limited to) a subsequent version 
of TLS.


I've spent some time today reading through the IDs. It has become clear
to me that in order for OpenSSL to be used to implement QUIC there are a
number of new requirements/issues we would need to address:

- We need to provide the server half of the TLSv1.3 cookie mechanism. At
the moment an OpenSSL client will echo a TLSv1.3 cookie it receives back
to the server, but you cannot generate a cookie on the server side.


Yeah, the cookie is pretty clear to the UDP/"stateless" operation.


- We need to be able to support *stateless* operation for the
ClientHello->HelloRetryRequest exchange. This is very much in the same
vein as the stateless way that DTLSv1_listen() works now for DTLS in the
ClientHello->HelloVerifyRequest exchange. This is quite a significant
requirement.


The expectation is that the state gets bundled into the cookie, yes.


- A QUIC server needs to be able to issue a NewSessionTicket on demand

- Ticket PSKs need to be able to have an embedded QUIC layer token (the
equivalent of the cookie - but embedded inside the PSK).


I think 
https://github.com/openssl/openssl/pull/3802
 is pretty close, in this space.


- We need to extend the "exporter" API to allow early_secret based
exports.

Re: [openssl-users] [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

[Short, Todd via openssl-users]

Ben Kaduk:

Do we know the values that are being passed to SSL_CTX_set_Verify_depth() match 
the -verify_depth argument, or do they differ?
If they differ, do identical arguments to the function behave the same in 1.1.0 
and 1.0.2?

Viktor:

What we’re getting at here, is that this appears to be a potentially 
significant behavioral change. We want to understand it better.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Apr 3, 2017, at 4:43 PM, Viktor Dukhovni 
mailto:openssl-us...@dukhovni.org>> wrote:


On Apr 3, 2017, at 4:26 PM, Benjamin Kaduk 
mailto:bka...@akamai.com>> wrote:

There was a fair amount of churn in x509_vfy.c with the inclusion
of the DANE stuff and whatnot, so it's not immediately clear to me
when this change actually happened.  I think there are good
arguments for the current 1.1.0 behavior and it doesn't really make
sense to try to change back to the historical behavior, but it would
be good to know when the change actually happened and that it is/was
a known change.  Ideally we could also document the different
behavior between 1.0.x and 1.1.0 better; any thoughts about where to
do so?

https://www.openssl.org/docs/man1.1.0/apps/verify.html

  -verify_depth num

Limit the certificate chain to num intermediate CA certificates.
A maximal depth chain can have up to num+2 certificates, since
neither the end-entity certificate nor the trust-anchor
certificate count against the -verify_depth limit.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify_depth.html

SSL_CTX_set_verify_depth() sets the maximum depth for the
certificate chain verification that shall be allowed for ctx.
(See the BUGS section.)
...
BUGS

The certificate verification depth set with SSL[_CTX]_verify_depth()
stops the verification at a certain depth. The error message
produced will be that of an incomplete certificate chain and
not X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected.

The 1.0.2 behaviour was under-documented and somewhat broken.  This
was fixed in 1.1.0.


Unfortunately, the SSL_CTX_set_verify_depth(3) was not brought up to date,
contributes welcome:

  https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_verify_depth.html

--
Viktor.

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

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

Re: [openssl-users] Building OpenSSL 1.0.1t without tls1.1 support?

[Short, Todd]

1.0.1 is old, and not really supported, except some security fixes.
1.0.x does not provide the ability to compile out TLSv1.0 from 1.1 from 1.2.
The upcoming 1.1.x does.

If you disable tls1, then you’ve also disabled all later versions, so enable 
tlsv1 at config time and use the SSL options to enable/disable the protocols at 
run time.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 22, 2016, at 3:08 PM, Scott Neugroschl 
mailto:scot...@xypro.com>> wrote:


I’ve done a custom build of OpenSSL where I ran Configure with “no-ssl2” and 
“no-ssl3”.  I’d like to disable TLS1 and 1.1 if possible.  Will the no-tls1 
option disable just TLS1 or all TLS1.x protocols?

Thanks,

ScottN



--
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] Openssl and floating point

[Short, Todd]

The -Ddouble=long hack might very well cause problems with standard headers.

I’m assuming you are not talking about x86 or any other platform for which 
there is assembly support.

In such a case, I suggest #ifdef’ing out the code that you don’t care about, 
and making it into a configuration option, the submitting a patch for it.
There may be some use for this configuration, especially on low-power IoT-type 
things.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 10, 2016, at 11:52 AM, Jakob Bohm 
mailto:jb-open...@wisemo.com>> wrote:

(Top posting for consistency in this part of the thread)

Note, however that emulated floating point tends to add code
size and startup overhead even when not called.

Hence the need to compile with an option to not use floating
point at all, at least on platforms that don't have platform-
specific optimizations via hardware floating point (such as
the SSE optimizations for some operations on x86 or the VFP
optimizations on later ARM hardware types).

Rich suggested a "hackish" preprocessor trick, which depends
on no current or future OpenSSL code using floating point in
a way that is seriously broken by that trick.

On 10/08/2016 16:51, Kyle Hamilton wrote:
This is compiler-dependent, and because you didn't specify what platform you're 
targeting or what compiler you're using, there's no way for us to provide an 
answer. Check your compiler's documentation.  GCC, for example, provides 
software-emulated floating point for platforms without hardware support.  Many 
other open-source and commercial compilers do as well.

On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman 
mailto:kgold...@us.ibm.com> 
>wrote:

   We have a platform that does not support floating point
   operations.  We discovered that openssl uses floating point in the
   random number generator.

   Is there any build or compile time flag that uses an alternative
   to floating point?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
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] different encrypted text for the same plain text message

[Short, Todd]

Rich Salz basically told this guy to read Wikipedia about cryptography… :)
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jul 28, 2016, at 11:15 AM, Benjamin Kaduk 
mailto:bka...@akamai.com>> wrote:

There are several places where a per-connection random input is introduced, 
with a specific goal of making encryptions of the same plaintext produce 
different ciphertexts (as well as other benefits).  If a plaintext always 
produced the same ciphertext, then an attacker could make a dictionary of 
different observed ciphertexts and know when the same plaintext was being 
repeated, which violates the confidentiality property desired from the protocol.

-Ben

On 07/28/2016 06:19 AM, R-D intern wrote:

Hello,
I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
tried understanding the mechanism handshake mechanism. What still quizzes me
is ; communication between a specific client -server for a specific session
generates different encrypted text for the same plain text message. What
leads  to this? Can anybody elaborate?
Please reply.
Thanks and regards,
Suman



--
View this message in context: 
http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html
Sent from the OpenSSL - User mailing list archive at 
Nabble.com.


--
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] ssl connect failed

[Short, Todd]

There are ALPN/NPN callbacks that need to be set. Documentation was added 
recently to 1.0.2:

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_alpn_select_cb.html

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Apr 20, 2016, at 5:53 AM, james sqawz 
mailto:james.sq...@gmail.com>> wrote:

Hi all,

I want to add two extension field in CLIENT HELLO request.

Extension: next protocol  negotiation
Extension:application layer protocol negotiation

For that purpose which API/function of openssl I will call?

Thanks
Pranab


On Mon, Apr 18, 2016 at 6:16 PM, james sqawz 
mailto:james.sq...@gmail.com>> wrote:
Hi all,

Thanks for the providing the forum for discussion on TLS/OPENSSL related issue.

I am very new to openssl.

Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
For that purpose I send connect request to the server,but connection is getting 
failed.

Following fields are abscent in my ssl packet.

Extension: server name present
Extension:application layer protocol negotiation

Apart from that I did not set path of Server Certificate.

Shall these impact my connect request.
Can somebody help.

Thanks
James

--
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] Problems with OpenSSL 1.0.2 h

[Short, Todd]

Have you tried to configure this cipher at the top of your cipher list 
initially with SSL_OP_SERVER_CIPHER_PREFERENCE?

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On May 4, 2016, at 12:04 PM, Benjamin Kaduk 
mailto:bka...@akamai.com>> wrote:

Hello,

On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
Hi,

I've trouble with the newest OpenSSL as I'm operating a webserver application
that answers with HTTP1.x and HTTP2.

I registered the ALPN callback and in this the cipher list was adjusted
"SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated.

With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
selection will be ignored, resulting in using a cipher that is black listed for
HTTP2 (Firefox and Chrome refuse to connect)

Was there an indented change or is there an official way to select the cipher
based on the ALPN extension value?


There was an intended change to the order in which ALPN extensions were
processed, see
https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599
-- ALPN is now processed after SNI, since the ALPN callback is attached
to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in
use.  It does look like "late" TLS extensions are now handled after
cipher selection, so the ALPN callback can no longer affect the
negotiated cipher.

Even at the specification level, how all the TLS extensions are supposed
to interact with each other and the rest of the handshake is not
terribly well specified, so adding -dev to discuss what the desired
behavior actually is.

-Ben
--
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] Decrypt TCP session

[Short, Todd]

Check out ssldump.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Feb 12, 2016, at 10:05 AM, Lloyd 
mailto:lloydkl.t...@gmail.com>> wrote:

Hi,

I have implemented a sample HTTP server/client based on openssl (boost asio) 
and able to send the message encrypted. Loaded the key in Wireshark and able to 
see the data in plaintext form.

Now I wish to write an application to decrypt the same "tcp session data" (tcp 
session data = the output of follow TCP stream option in Wireshark).

what should be the starting point to implement this? does open ssl have some 
sample code/application does this?

Any hint is greatly appreciated.

Thanks,
  Lloyd

--
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] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Short, Todd]

I suspect that most “users” of OpenSSL are doing it indirectly through other 
applications that use TLS (or crypto) functionality. Example: the Cisco 
AnyConnect client is reportedly one of the most installed pieces of software 
regardless of platform; it uses OpenSSL for TLS.

Taking those indirect users into account, they don’t care about the research or 
advanced uses of OpenSSL; they just want to connect securely to their corporate 
network.

--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Nov 20, 2015, at 9:09 PM, Peter Waltenberg 
mailto:pwal...@au1.ibm.com>> wrote:

Quite reasonable except.

I'm not sure you have majority and minority the right way around. My guess 
would be that the majority of OpenSSL users are libcrypto. consumers rather 
than SSL/TLS consumers.

A point several of us have been trying to get through for some time.

Peter

-"openssl-dev" 
mailto:openssl-dev-boun...@openssl.org>> 
wrote: -
To: "openssl-...@openssl.org<mailto:openssl-...@openssl.org>" 
mailto:openssl-...@openssl.org>>
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" 
mailto:openssl-users@openssl.org>>
Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from 
OpenSSL 1.1 - seeking feedback

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality that most people care about, basically SSL/TLS connectivity.

--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
mailto:u...@ll.mit.edu>> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
mailto:openssl-dev-boun...@openssl.org> on 
behalf of bka...@akamai.com<mailto:bka...@akamai.com>> wrote:

On 11/18/2015 07:05 AM, Hubert Kario wrote:
So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?

Because it used to be the only real game in town, and *people learned to
rely upon it*.

Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .

___
openssl-dev mailing list
To unsubscribe: 
https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=wLKbuAEIg97aXrny3BLz9t

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Short, Todd]

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality that most people care about, basically SSL/TLS connectivity.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
mailto:u...@ll.mit.edu>> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
mailto:openssl-dev-boun...@openssl.org> on 
behalf of bka...@akamai.com> wrote:

On 11/18/2015 07:05 AM, Hubert Kario wrote:
So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?

Because it used to be the only real game in town, and *people learned to
rely upon it*.

Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .

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

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