[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] "quality" of keyservers offering hkps

From: Matthias Schreiber
Subject: [Sks-devel] "quality" of keyservers offering hkps
Date: Thu, 14 Aug 2014 00:33:47 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0

Hash: SHA256

Hi everyone,

after reading the posts related to protocols and cipher suites started
by Pete last week [1] I wanted to check the settings of the keyservers
in the hkps pool using the SSL Server Test from Qualys [2] in order to
evaluate the "quality" of the applied settings.

Ignoring the "untrusted certificate" warnings, these are the compact
results of the test using Qualys' grade system:

A- or better    23 servers
B               2 servers
C               1 server
F               9 servers

So, from the total of 35 servers (of which 3 aren't currently in the
hkps pool due to missing keys) basically 2/3 show secure and robust

5 servers (grades B and C as well as 2 from the F group) have lower
standards on different levels by either not supporting modern
protocols like TLS 1.1 & 1.2 and/or allowing weak or even insecure
cipher suites. Here, an improvement would be to apply a more secure
configuration [3] as e.g. already suggested in the aforementioned
thread [1].

In case of the last remaining 7 servers (= every 5th server) the test
showed an exploit opportunity related to CVE-2014-0224 [4], which can
be eliminated by simply updating the OpenSSL package on these systems.
As I'm not that much deep in the topic I'm not sure about the impact
of this issue on the security of hkps connections. Perhaps anyone can
give an advise here. Could this be a threat and should be also checked
before including servers to the hkps pool?

In general, is this kind of test useful to find possibly weak servers
in the mentioned pool? Should it be done on a regular basis perhaps or
is of low relevance?


- ---------





Version: GnuPG v1


reply via email to

[Prev in Thread] Current Thread [Next in Thread]