[LEDE-DEV] [PATCH] mbedtls: Re-allow SHA1-signed certificates

[Magnus Kroken]

Hi

On 04.08.2017 18:37, Hauke Mehrtens wrote:
> I agree to put this into LEDE 17.01 and the master branch for now.

It should be merged to LEDE 17.01 to maintain feature compatibility. I 
disagree that it should be merged to master, as this is a feature we 
(should) want to break in the long run.

> There are probably a lot of old certificates out there that are still in
> use and are SHA1. As the public CAs are not issuing any SHA1
> certificates any more and creating a own certificate and not just
> modifying an existing is certificate is harder, I think there is no big
> security problem here.

Let's take the two examples brought up so far - certificates used with 
OpenVPN, and certificates used with general HTTPS connections.

1. HTTPS
As you said, public CAs have not issued SHA-1 certs for some time. In 
addition, all major desktop web browsers consider sites with SHA-1 certs 
insecure, and throw big fat warnings in the face of users if they 
connect to one. Any site that wants any visitors at all will either 
offer their sites over HTTP only, or install a new cert with SHA-256 
fingerprint. The major browsers have already put their combined force 
together to push for security over compatibility. I don't see why we 
should pull in the opposite direction, given that our influence in this 
context is insignificant in comparison.

2. OpenVPN
OpenVPN does not rely on the public CA system, so the changes in that 
regard does not push OpenVPN servers/providers to do anything about 
their setup (trusting a public CA in an OpenVPN setup greatly reduces 
the security).

The issue I have in this case isn't that "security trumps everything 
everytime", but that it puts all users at risk. When we help out the 
people who still have some work to do with their services, we also put 
the people who have done their homework at risk, with no easy way out. 
I can't tell my OpenVPN server to only trust certs with SHA-256 
fingerprints, because OpenVPN trusts the TLS library to decide which 
algorithms are acceptable and which are not. This isn't specific to 
OpenVPN, most applications provide little or no tweaking of these things.

Since mbedTLS is not runtime-configurable, the question becomes "who 
should we tell to compile their own library to fix their issue?", be it 
security concerns or compatibility issues. In the master branch, I think 
it's fair to make such a breaking change now - we aren't early birds in 
this regard, web browsers have been forcing people to fix their certs 
for more than 6 months now.

Regards
/Magnus