hello hello ladies and gentlemen the
next uh presentation is Mr zeelard
Pfeiffer
[Applause]
thank you can you hear me
okay cool uh just a minute
I try to share my presentation
and also this terminal
okay that's it
I hope so
so let's start it
um my name is silat Pfeiffer I graduated
as an electrical engineer your engineer
as almost 20 years ago since then I have
been working in I.T security I started
my career as a software developer and I
am I am a security engineer and
evangelist as you can see on the slide
I work at Ebola Society security which
which is one of the few Hungarian United
Security vendors
a formerly this company was called
balabit this was the vendor of the
syslog NG now we are the member of an
application of a firewall and the API
lifecycle management platform uh the
story has started with the measurement
of day heat attack which is a denial of
service attack against the DV element
protocol I wanted to measure how
vulnerable the different cryptographic
libraries are against this day heat
attack I had to realize that there are
significant differences between
different cryptographic libraries but I
also realized that there are significant
difference between the openness version
1.1 and 3.0 which is the latest version
of the openssl I would like to present
uh how some default values in the
openssl version 3.0 can multiply the
potential of day heat attack for
millions of servers
before I could continue I should explain
the day heat attack
but it is necessary to talk about key
exchange because the heat attack is a
denial of service attack against the DVR
monkey Exchange
all cryptographic protocols have a part
called key exchange but what is it
parties intends to communicate with each
other in a secular manner need a
symmetric key a shared secret it's
practically just some kind of random
data which will be used to encrypt and
deck the messages in a symmetric way
uh why is it exploitable there are two
reasons for that the first one is that
the key change algorithms are more or
less CPU intensive depending on the
specific case change algorithm the
second reason is uh that the key
exchange is unauthenticated
in the case of the cryptographic
protocols the key exchange precedes the
authentication so it means that an
unlock authenticated client can enforce
the server to do CPU intensive operation
without Authentication
what's the problem with the DVR monkey
exchange the problem is that the Divya
monkey is choosing more CPU intensive
than the other key exchange algorithms
such as RSA or the elliptical version of
the DVR monkey Exchange
the other problem is that the
computational capacity requirement of
the DVR monkey exchange increases along
with the public and the private key
sizes as DVR monkey is changing
asymmetric algorithm
to understand how an auto care can
exploit this I have to talk about the
DVR monkey Exchange
first of all the parties have to agree
in two numbers the first one is a
generator the second one is a prime
these are public parameters of the
different key exchange and this
agreement can be done part of the crypto
cryptographic handshake after that a
client picks a random number this will
be its private scheme and computes the
generator to the power of this private
key mod the prime
this operation is the modular
exponentiation this is the CPU intensive
part of the DVR monkey Exchange
as a result of the modular
exponentiation the result of the modular
exponentiation will be the public key in
the DVR among key exchange the client
will send this public key to the server
meanwhile the server does the same
operations and the board is receiving
each other public key can compute the
shared secret using the same operation
the modular exponentiation so the
modular exponentiation is done twice
during the DVR monkey Exchange
most parties do the same operations
so the computational capacity
requirement is the same both on the
client and the server side in a normal
case but it is not ideal if you were to
pair if you you are an attacker and you
want performance denial of service
attack so you have to cheat somehow the
protocol to decrease the
computation cost publicity requirement
on the autocash side
how and other care can do that
key is that you have to avoid the
modular exponentiation it can be done
it's relatively easy uh the client
demolishes client does not pick any
random number as it unnecessary as you
will see
it does not compute the modular
exponentiation
instead it just speaks a number which is
less than the prime because it is
guaranteed that the result of the
modular exponentiation is less than the
prime
so the client the malicious client can
send this peaked value to the server but
the server cannot distinguish it between
the uh from from the uh from a computed
public key because it's just a number
the server performs the modular
exponentiation twice
with this mechanism a malicious client
can force the server to perform the CPU
perform CPU intensive operations without
any computational requirement on the
autocash side
so in this way the differential monkey
exchange can be hacked
it it doesn't mean that it is about the
confidentiality uh the DVR monkey
exchange is completely secure it is
about availability
so you have a way to perform a denial of
service attack
but what's the problem with the open SSL
version 3.0
the issue comes from uh two reason the
first one is that in in the openness sub
version 3.0 they started to support the
DVR monkey Exchange in TLS 1.3 and it is
enabled by default using
um the largest possible group size this
group size is the uh it determines the
public key size the other reason is that
the open SSL developer is very
implemented the DPL monkeys change in
the version open SSL 3.0 and they use
this they use large exponent size
meaning that the private key will be
large also
in the case of the TLs 1.3 the client
can enforce the server to use the
largest possible public key size
this is how the DS 1.3 works it means
that the public key will belong
s of the ray implementation in open SSL
3.0 the private key size will be also
long as I mentioned the the CPU capacity
requirement in the case of the DVR
monkey exchange along increases along
with the private and public key sizes so
the effect will be that the exposure to
the heat attack is dramatically
increased
however there are two product visits the
first one that TLS 1.3 is enabled on the
server but this is the case in 40 more
than 45 percent of the web servers in
the top 150 000 domains uh this um
this ratio was uh 45 percent one year
ago so that was at the 10 increasement
in the last year
the second prerequisite is that the
server use the default name groups
in the case of the most popular web
servers Apache and nginx they
um they fall back to the open SSL
default so if a maintainer does not
explicitly set the named groups in the
configuration of the verb server it will
use the open SSL default
so after the theoretical explanation
let's let's see a demo
thank you
in the left side you can see the open
cell version
3.0.5 this is the last affected version
hopefully
and on the right side you can see the
open version
3.0.6 which will be in the next release
of openssl and there will be a fix here
I use the open SSR command line tool to
generate diffie-hamon public keys
as you can see
um
if if the key size the public key size
is 8kb bits This Server is it's just a
digitalization instance so not a it's a
relatively small machine but it can
generate only three DVM on public Keys
per second if long exponents are used
compared to the left side where small
exponents are used in that case with
8kbit public Keys almost 50
different public keys can be generated
so there are huge difference between the
two versions
go back to the presentation
as you could see the performance of the
DPM on public key Generation
Um decreased significantly meaning that
the effectiveness of the day heat attack
increased significantly
in the case of open SSL 1.1
the DVR amount wasn't enabled in the
case of TLS 1.2 and it wasn't supported
in the case of DLS 1.3
uh there were some elliptic curves
enabled by default the slowest key
exchange mayonnaise was the elliptic
curve the DVR monkey exchange using the
curve and istp 521
in the case of openssl 3.0 the default
contains the DVR monkey exchange a bit
the same elliptic curves but the default
also contains the finite field
parameters from 2kbit Key size to 8 GB
key size it means that the slowest key
exchange melaninism will be the DVR
monkey exchange with the 8kbit Finish
field DVM on fmr parameter the CPU
requirement is
50 to 90 times higher than is it was in
the case of openness 1.1 using the
default settings of named groups
the problem is that this issue cannot be
fixed completely
the next release of open SSL we use
small exponents instead of long ones
but the openssl default of named groups
cannot be changed so it will also still
contain a definite field if you are on
fabera parameters with key size is from
2kbit to 8 kbbit because they cannot
change the default value according to
their versioning policy
um so the slowest uh key exchange
algorithm will be the ddpr monkey
exchange still with the aqbit key size
but it will be much faster than as it is
in the current version of the openness
3.0 using the small exponent
the DVR monkey is changed with 4kbit key
size has the same performance
as the slowest elliptic curve DVR
monkeys change the nistp five to one
um the performance of the DVR monkey
exchange with 8kbit key size will will
be almost five times slower than the
slowest elliptic curve DVR monkey
Exchange dni stp521
so the effectiveness of the day at the
attack after the fix will be five times
higher than it was in the case of open
SSL 1.1 independently from the fact that
uh small exponents will be used instead
of long ones
what if I compare the performance of the
different among key exchange not to the
slowest elliptic curved if you are
monkey exchange but the most popular one
earlier I compared the slowest key
exchange in open SSR 1.1 to this lowest
key exchange in open SSL 3.0 because it
demonstrates that what is the what what
the result of the default changes in
open SSR 3.0
how it changes the effectiveness of the
day heat attack on this slide
uh I compare the diffie-harmon key
exchange using three kbbit key size with
the most popular elliptic curves the
nistp-256 and the
x25519 because
these ellipticals provide the same
security strength as the DVR monkey
exchange with 3kbit key size as you can
see the elliptic curved here among key
exchanges much faster providing the same
Securities tanked and istp
256 almost even almost 20 times faster
than the DVR monkey exchange
x25519 even almost 30 times faster than
the ddpr monkey exchange using the 3kbit
key size
um elliptic curve s x 449 which provides
much more security tracks strength than
the earlier mentioned elliptic curves
still even almost six times faster than
the DVR monkey Exchange
the question arises what you should do
to avoid the exploitation of this day
heat attack
in the case of the TLs 1.2 to you should
use well-known DVR parameters for
instance Dimension infinite field if you
are on parameters or the mod P DPM and
parameters because open SSL 3.0 uses
small exponents
uh only if you use their loan DVR amount
parameters
the other option is to set the private
key length in the DPL parameter file
which was generated by open SSR command
line tool unfortunately the open SSR
command line tool is not suitable either
to generate DV hormone parameter file
with set small exponent size or set it
afterwards
in the case of the TLs 1.3
you should set the name groups
explicitly to avoid issues like that
which comes from uh not so correct
default values of the cryptographic
library
to ensure compatibility I would suggest
to offer the
nistp-256 but I also just suggest to
prefer the x29
25519 elliptic curve because it was
designed by an intermittent researcher
daniaji bergerstein
and I would uh suggest to you to not
consider not to use the different
exchange key exchange with larger public
Keys sizes because the strength of the
three key bit key size is equivalent to
the security strength of AIS
120 H according to the nist
um if you are interested in the the heat
attack you can find a comprehensive
information on its official website this
is the Heat attack.com and I also
published a command line tool which can
be used to set the private key size in a
different parameter file I published it
on the GitHub page of the proof of
concept implementation of the date
attack called day heater thank you for
your attention
foreign
any questions from the audience while
we're here right
thanks for that
um in terms of the research you did are
there any other areas of interest that
you are exploring or was this the
this is the main outcome but are there
any other interesting areas that you
sort of thought that it doesn't pass the
sniff test yeah absolutely
but it is not not just an accident I
haven't talked about that yet because
there are some
um issue investigation in progress with
other cryptographic libraries uh but um
but you know it's it's confidential in
the case of the openssl it's okay to
talk about it because they consider it
as a performance issue not a security
issue and the
um fix is publicly available and the
issue was fixed completely in public so
it wasn't confidential ever
yes
so the confidential uh let's say
research that's not related to open SSL
yeah it's not not related to work on a
cell okay thanks
thank you very much uh if there are any
further questions
um there is one there we have time for
one more
thank you sir thank you uh my question
is has this been exploited in the wild
are there documented cases
very good question I'm also interested
in the answer
because uh there were some attacks
against Google and also the cloudflare
and they communicated that that
encrypted connection was used
to perform a denial of service attack
against us but I don't know anything
about the details of these attacks and I
wanted to communicate with them but it's
not so easy you know
because it's Google so right okay thank
you you're welcome
thank you zeelard that's great we um
have to move on to the next presentation
which will be in a few minutes uh
zeelard will be around
for the rest of the day if there are any
other questions he'd be happy to talk to
you