[Cryptography] TLS 1.0, Diffie-Hellman, RSA, AES128 CBC, SHA seriously qualified as «broken»?

[Thierry Moreau]

Hi,

A weird observation from my experimentation with open source security
software.

I installed an Apache server with a single TLS profile which I believed 
robust in spite of being a bit outdated. I prioritized Diffie-Hellman 
for «forward secrecy», considered RSA, AES128 CBC, and SHA valid choices 
despite a bulk encryption key size in the low range. I assumed that a 
recent openssl library would implement the most needed countermeasures 
for known veakenesses in TLS 1.0.

I configured the thing HTTPS-only and requiring client certificate in 
all cases. Indeed I recorded that a friendly certificate «subject public 
key» was used in the connection (through apache SSL environment 
variables ...).

In essence, it appears to work as intended.

The Firefox version 76.0.1 reported «TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
128 bit keys, TLS 1.0» as the technical details for the security of the 
web page.

In essence, it appears to work as intended ... but

The firefox browser qualifies this as «broken encryption». «Your 
connection to this website uses weak encryption and is not private. 
Other people can view your information or modify the website's behavior. 
Information sent over the Internet without encryption can be seen by 
other people while it is in transit.»

And the security icon on the left of the URL entry field is yellow.

Then what?

Am I too old to craft an apache/openssl secure configuration? Indeed I 
am reluctant to chase a configuration including Diffie-Hellman forward 
secrecy that would fate better in the Firefox security assessment.

How can I claim that this is secure to third parties?

- Thierry Moreau

(In case you want to try with a different client browser, this listens 
on the public Internet but requires a client certificate. Since I trust 
only individually selected end-entity certificates as roots of trust, 
you need to send me your application «out-of-band» with a motivation 
letter ... OK, off-list e-mail might allow you a short cryptoperiod of 
trust -- I reserve the right to limit the not-after field in the 
certificate. Public key algorithms other than RSA or with short modulus 
will be rejected without contacting the applicant!)