summaryrefslogtreecommitdiff
path: root/faq.wml
blob: dc51594e28e7ddf2d95999eafbc4a1cfaa6d518c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#include 'common.wml' page="Frequently asked questions"

<p>Answers to common questions follow.
</p>

<div class="emph-box" id="prime-not-acceptable">
  <h1><a href="#prime-not-acceptable">The software I use outputs the following error:
"The Diffie-Hellman prime sent by the server is not acceptable (not long enough)"
and the connection is terminated.</a></h1>
  <p><b>Answer:</b>
The server you have tried to connect negotiates Diffie-Hellman (DH) ciphersuites
but offers a small and insecure DH group. This means that any connection data 
could be decrypted in weeks or even hours by a determined adversary. For that 
reason GnuTLS will refuse to communicate such servers. To work around the issue disable Diffie-Hellman
ciphersuites on the client (by using "NORMAL:-DHE-RSA" as a priority string);
this will force connecting using the plain RSA ciphersuites, at the cost
of losing perfect forward secrecy. 
  </p>
  <p>
Note that currently in the NORMAL priority string, the minimum acceptable
size of DH group is set to be at 768 bits. This is a very low size for
today's threats but unfortunately there are many popular Internet servers
providing such a weak security level. To increase the security level use
the SECURE128 or better priority strings, at the risk of a failed connection
with an insecure server. To avoid this issue, newer versions of GnuTLS prioritize the elliptic
curve DH ciphersuites that have no such issues (since the curve is negotiated
as part of the handshake).
</p>
</div> 

<br>

<div class="emph-box" id="key-usage-violation">  
<h1><a href="#key-usage-violation">"The software I use outputs the following error:
"Key usage violation in certificate has been detected."
and the connection is terminated.</a></h1>

<p><b>Answer:</b>
The server you have tried to connect has its certificate marked for
encryption-only but the server uses it with a ciphersuite that requires signing (or vice-versa). This is
either due to an attack, or due to a serious server misconfiguration. 
Contact the server administrator. <br/>
Because this misconfiguration problem is widespread, other TLS/SSL 
implementations used by popular browsers tolerate the violation, and several 
servers negotiate ciphersuites not allowed by the certificate, newer 
versions of GnuTLS will also allow such key usage violations (and will only output a warning message).
</p>
</div>

<br>

<div class="emph-box" id="key-usage-violation2">  
<h1><a href="#key-usage-violation2">"The server software I use outputs the following error:
"Insufficient credentials for that request." after a client connects.</a></h1>

<p><b>Answer:</b>
If the server uses an X.509 certificate with an RSA key, then most probably the server certificate doesn't allow
any of the ciphersuites requested by the client (this is related to <a href="#key-usage-violation">key-usage-violation</a>).
There are three possibilities:
<ul>
<li>The server has a priority string that incorrectly restricts the available ciphersuites to
the set not allowed by the certificate. Solution: If the server has a certificate with the
Key Usage extension and digitalSignature set, make sure that DHE-RSA and ECDHE-RSA key exchange
methods are enabled. If the keyEncipherment flag is set, then make sure that the RSA key exchange is enabled.</li>
<li>The client requires only encryption ciphersuites (i.e., RSA) but the server certificate only 
allows ciphersuites with signing (e.g., DHE-RSA). Solution: If the server has the Key Usage extension
with digitalSignature set, replace or (better) add another server certificate with keyEncipherment set.
</li>
<li>The client requires only signing ciphersuites (e.g., DHE-RSA) but the server certificate only 
allows ciphersuites with encryption (i.e., RSA). That is the server has the Key Usage extension
with keyEncipherment set. Solution: If the server has the Key Usage extension
with keyEncipherment set, replace or (better) add another server certificate with digitalSignature set.</li>
</ul>

Note that while having a single certificate with the Key Usage extension unset, or with both
digitalSignature and keyEncipherment flags would solve the issue; it is considered bad practice 
to use a single key/certificate for both RSA encryption and signatures.
</p>
</div>

<div class="emph-box" id="Dual_EC_DRBG_info">  
<h1><a href="#Dual_EC_DRBG_info">I heard about the backdoor in http://en.wikipedia.org/wiki/Dual_EC_DRBG, does it affect GnuTLS?</a></h1>

<p><b>Answer:</b>
GnuTLS never supported the Dual EC random generator, hence this issue does not affect GnuTLS.
</p>
</div>

<br>

#include 'bottom.wml'