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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
