[Info-vax] OpenSSL CSWS-2.2-1

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Wed Jun 5 23:09:30 EDT 2019


On 2019-06-04 14:57:41 +0000, doug80638 at aol.com said:

> "I also feel that the interface to the product should be 
> somehowcompatable rather than needing re-coding to use the newer stuff. 
>  Notsure how easy that might be. "
> 
> Easier said than done. Making internal structures opaque that were once 
> directly visible and modifiable precludes forward compatibility.

Assuming folks call OpenSSL directly, quite correct.

Also welcome to why I've suggested wrapping the existing APIs.

I've previously released a descriptor-friendly set of wrappers for 
OpenVMS and OpenSSL.  That wrapper API could undoubtedly be done better 
than what I designed, too.  But it works.  I'm aware of and have 
previously linked to other wrappers for other platforms.

Welcome to why I keep grumbling about upward compatibility and the 
inherent conflicts with fixing stuff and deprecating older APIs, too.

> Silo'd coexisting releases at least allow customers to continue to run 
> their current applications until such time as they can, if ever, update 
> their source code.
> 
> "So, whynot some type of configuration tool that can set flagsas to 
> which protocols should be allowed?  Default it to TLS3, but allowwhen 
> necessary for older protocols to be allowed."
> 
> The handshake does this now by connecting to the strongest protocol 
> enabled by both sides. Applications can set options to limit which 
> protocols are available during the handshake. For instance, you can 
> restrict protocols to SSL3 and TLS1.3 and ignore the three TLS versions 
> in between.

Or with a wrapper, let that deal with selecting the requisite TLS 
settings and the other details of the various OpenSSL APIs—preferably 
also dealing with DNS and sockets and certificates and related baggage, 
and preferably AST- or KP-friendly—and allow the wrapper to upgrade 
connection security as newer implementations are available and/or as 
older implementations become vulnerable.

ps: If I don't ever have to deal with another nonce in my 
encryption-related code again, it'll be too soon...
https://eprint.iacr.org/2019/624


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list