Dear sci.crypt,

On the off chance this message is not drowned in spam, and there are
still people reading s.c., here goes.

Is there a checklist of what to do, what to adhere to, when implementing
TLS (and SSL for that matter)? The reason I'm asking is because of the
following two security advisories, covered in

https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/

https://www.theregister.com/2020/06/10/gnutls_patches_security_hole/

neither of which are saved by /rewriting it in memory safe language/.

I have read the book /Bulletproof SSL and TLS/, which is really about
using these things correctly, and not about how to implement it safely.

Thanks,
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

On Sun, 24 Sep 2023 10:41:30 +0800
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

> Dear sci.crypt,
>
> On the off chance this message is not drowned in spam, and there are
> still people reading s.c., here goes.
>
> Is there a checklist of what to do, what to adhere to, when
> implementing TLS (and SSL for that matter)? The reason I'm asking is
> because of the following two security advisories, covered in
>
> https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/
>
> https://www.theregister.com/2020/06/10/gnutls_patches_security_hole/

"All their 'rotation' did was add a vulnerability," he said."

Of course none of this is ever intentional ...
> neither of which are saved by /rewriting it in memory safe language/.

Perhaps file a bug about the design of the protocol itself ...
> I have read the book /Bulletproof SSL and TLS/, which is really about
> using these things correctly, and not about how to implement it
> safely.
>
>
> Thanks,

By "implement" do what do you mean? Do you mean implementation from
scratch using your own source code? Or do you mean implementation with
standard libraries of a particular toolchain or operating system? What
langauge are you using? What build setup? What architecture? Please be
more specific about "implementation" fundamentals.

The RFCs would be the most logical place to begin.

The safest approach is to create your own constant-time, dependency-free
unit for doing the cryptographic functions. This way you are not
shifting trust to someone else to have implemented their library
correctly. Your custom library should only perform the necessary
functions and have no other functions in the code logic. Extraneous
functions can mean extra attack surface. Swiss army knives can be a
dangerous option security-wise.

If you are using some standard library you can get the source and strip
out everything your application does not use then re-compile and test
from that foundation. In doing an implementation it is important to
digest the RFCs or spec documents and have others look at the
implementation source for bugs before using it.

Personally, if I had to implement cryptography from source for a
high-traffic or mission-critical application I would only use one of the
old languages, like C, Pascal, or Ada. I would stay away from boutique
languages and the newer ones like Go and Rust. I would try to avoid
using bloated languages like Java, Python, Ruby, etc. If it is not a
high-traffic or critical application I might use shell scripts to glue
together GNU tools and commands for openssl, gnupg, nettle, etc. only
using what I know to be secure in those applications. Using this method
you can insert your own extra checks into the shell code, to trap
any potential exploits that the library code is not designed to handle.
So even if there lurks some zero days, you can have checks and
remediations in place that prevent them from working. This might not be
enough to thwart a bug on the other end of the connection.

Personally, I consider anyone else's cryptography untrusted by default
until able to verify. I like to wrap it to do checks, one step at a
time in negotiation. I've witnessed enough moral turpitude in the hacker
space to assume everything is untrustworthy until otherwise verified.
I've also witnessed cryptologists and hackers say some really stupid
things that made me question their judgment.

If you have the skill and time to implement from scratch that is the
best route to avoid potential hidden vulnerabilities. Then you don't
have to trust the morality or judgment of others for the security of
your system. You can't have heartbleed if there is no heartbleed code
in your unit.

--
3883@sugar.bug | web: sybershock.com | news: alt.sources.crypto

On 9/24/2023 12:23 PM, Sugar Bug wrote:
> On Sun, 24 Sep 2023 10:41:30 +0800
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>
>> Dear sci.crypt,
>>
>> On the off chance this message is not drowned in spam, and there are
>> still people reading s.c., here goes.
>>
>> Is there a checklist of what to do, what to adhere to, when
>> implementing TLS (and SSL for that matter)? The reason I'm asking is
>> because of the following two security advisories, covered in
>>
>> https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/
>>
>> https://www.theregister.com/2020/06/10/gnutls_patches_security_hole/
>
> "All their 'rotation' did was add a vulnerability," he said."
>
> Of course none of this is ever intentional ...

Thanks for replying. Further comments in-situ, below.

>
>> neither of which are saved by /rewriting it in memory safe language/.
>
> Perhaps file a bug about the design of the protocol itself ...
>
>> I have read the book /Bulletproof SSL and TLS/, which is really about
>> using these things correctly, and not about how to implement it
>> safely.
>>
>>
>> Thanks,
>
> By "implement" do what do you mean? Do you mean implementation from
> scratch using your own source code? Or do you mean implementation with
> standard libraries of a particular toolchain or operating system? What
> langauge are you using? What build setup? What architecture? Please be
> more specific about "implementation" fundamentals.

Here I'm thinking more about a human-readable checklist, rather than
some technical protocol-level details. To try to explain my thought
pattern, I'm going to use Oracle's Java rewrite [linked above] as an
example.

Here, the JDK developers rewrote the SSL [1] implementation /in a memory
safe language/, and introduced a serious flaw. The heart of the flaw is
that someone at Oracle made the management/business decision not to
include cryptography experts [2] in the project. We cannot apply the
argument that Oracle doesn't have enough resources to include such a
person, though we can possibly apply it to GnuTLS.

So, not to be dragged into the technical details of how to implement
cryptography, or the SSL layer on top, for now, I'm considering a check-
list of /best practices/, or /standard operating procedure/, when doing
so.

Where, obviously, the checklist includes

* do not make Heartbleed,

* do not make Oracle's mistake, and

* do not make the GnuTLS mistake,

* and so forth.

I'm not sure that's sufficient to really explain what I'm thinking about
at the moment, but it's a start.

[1] I prefer that name, because I'm not being paid by Microsoft to
prefer TLS. It's the same thing at the protocol level anyway.

[2] A person trained in attacking cryptography implementations.

>
> The RFCs would be the most logical place to begin.
>
> The safest approach is to create your own constant-time, dependency-free
> unit for doing the cryptographic functions. This way you are not
> shifting trust to someone else to have implemented their library
> correctly. Your custom library should only perform the necessary
> functions and have no other functions in the code logic. Extraneous
> functions can mean extra attack surface. Swiss army knives can be a
> dangerous option security-wise.
>
> If you are using some standard library you can get the source and strip
> out everything your application does not use then re-compile and test
> from that foundation. In doing an implementation it is important to
> digest the RFCs or spec documents and have others look at the
> implementation source for bugs before using it.
>
> Personally, if I had to implement cryptography from source for a
> high-traffic or mission-critical application I would only use one of the
> old languages, like C, Pascal, or Ada. I would stay away from boutique
> languages and the newer ones like Go and Rust. I would try to avoid
> using bloated languages like Java, Python, Ruby, etc. If it is not a
> high-traffic or critical application I might use shell scripts to glue
> together GNU tools and commands for openssl, gnupg, nettle, etc. only
> using what I know to be secure in those applications. Using this method
> you can insert your own extra checks into the shell code, to trap
> any potential exploits that the library code is not designed to handle.
> So even if there lurks some zero days, you can have checks and
> remediations in place that prevent them from working. This might not be
> enough to thwart a bug on the other end of the connection.
>
> Personally, I consider anyone else's cryptography untrusted by default
> until able to verify. I like to wrap it to do checks, one step at a
> time in negotiation. I've witnessed enough moral turpitude in the hacker
> space to assume everything is untrustworthy until otherwise verified.
> I've also witnessed cryptologists and hackers say some really stupid
> things that made me question their judgment.
>
> If you have the skill and time to implement from scratch that is the
> best route to avoid potential hidden vulnerabilities. Then you don't
> have to trust the morality or judgment of others for the security of
> your system. You can't have heartbleed if there is no heartbleed code
> in your unit.
>

Yes, that is certainly my end-goal, but I'm only starting to work on
those skills, and I have only just begun that journey. One thing I've
noticed, is that /the proper skillset/ does include attacking other
people's cryptography, because it's necessary part of a comprehensive
testsuite.

In concrete terms, I'll probably start by learning from Tom St Denis,
and his libtomcrypt. It seems like a good start, at least at the
outset.

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

On 2023-09-24 09:39, Johann 'Myrkraverk' Oskarsson wrote:
> On 9/24/2023 12:23 PM, Sugar Bug wrote:
>> ...
> [1] I prefer that name, because I'm not being paid by Microsoft to
> prefer TLS.  It's the same thing at the protocol level anyway.
>

TLS was so named by the IETF (not Microsoft) because the SSL trademark
was the apparently the only part not not legally transferred to the IETF
when they took over protocol developent. In so doing, the IETF started
the official version numbering over at 1.0, but sanely continued the
in-protocol numbering from 3.1 . So add 2.1 to the TLS version to get
the in protocol SSL version.

MS had so little to do with TLS that they kept TLS 1.0 disabled by
default for many years in their browsers, forcing websites to keep SSL
3.0 enabled for IE compatibility.

TLS 1.3 development was so heavily dominated by Google that it is
effectively a Google protocol .

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