summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDirk Wetter <dirk@testssl.sh>2015-06-22 14:06:49 +0200
committerDirk Wetter <dirk@testssl.sh>2015-06-22 14:06:49 +0200
commit4024c260ead585eeaf02a5be36b9f34051322c42 (patch)
tree83a191defc984e4fb40c7e9abe275c3ad8cce1b0
parente63375ecaa2eb6042c734b2ab0c1b1ddccfbdf5b (diff)
downloadserver-side-tls-4024c260ead585eeaf02a5be36b9f34051322c42.zip
server-side-tls-4024c260ead585eeaf02a5be36b9f34051322c42.tar.gz
server-side-tls-4024c260ead585eeaf02a5be36b9f34051322c42.tar.bz2
External links
Typos / Syntax was for internal links (MediaWiki)
-rw-r--r--Server_Side_TLS.mediawiki10
1 files changed, 5 insertions, 5 deletions
diff --git a/Server_Side_TLS.mediawiki b/Server_Side_TLS.mediawiki
index 1c00ffd..61d69a9 100644
--- a/Server_Side_TLS.mediawiki
+++ b/Server_Side_TLS.mediawiki
@@ -277,10 +277,10 @@ For this reason, the use of this group is considered unsafe and you should eithe
* disable DHE altogether, relying on ECHDE for PFS if you don't support legacy clients lacking ECDHE support (see [[#DHE_and_ECHDE_support]]).
It is currently assumed that standardized 2048 bits DH groups provide sufficient security to resist factorization attacks. However, the careful administrator should generate a random DH group instead of using a
-standardized one when setting up a new server, as advised by the [[https://weakdh.org|logjam]] authors.
+standardized one when setting up a new server, as advised by the [https://weakdh.org/ logjam] authors.
== DHE and ECDHE support ==
-Most modern clients that support both ECDHE and DHE typically prefer the former, because ECDHE provides faster handshakes than DHE ([[http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html]], [[http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html]]).
+Most modern clients that support both ECDHE and DHE typically prefer the former, because ECDHE provides faster handshakes than DHE ([http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html], [http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html]).
Unfortunately, some widely used clients lack support for ECDHE and must then rely on DHE to provide perfect forward secrecy:
* Android < 3.0.0
@@ -361,7 +361,7 @@ The current recommendation for web servers is to enable session resumption and b
= HSTS: HTTP Strict Transport Security =
-[[https://tools.ietf.org/html/rfc6797 HSTS]] is a HTTP header sent by a server to a client, indicating that the current site must only be accessed over HTTPS until expiration of the HSTS value is reached.
+[https://tools.ietf.org/html/rfc6797 HSTS] is a HTTP header sent by a server to a client, indicating that the current site must only be accessed over HTTPS until expiration of the HSTS value is reached.
The header format is very simple, composed only of a '''max-age''' parameter that indicates when the directive should expire. max-age is expressed in seconds. A typical value is 15724800 seconds, or 6 months.
<pre>
@@ -372,11 +372,11 @@ HSTS is becoming more and more of a standard, but should only be used when the s
= HPKP: Public Key Pinning Extension for HTTP =
-See [[http://tools.ietf.org/html/rfc7469 RFC7469]].
+See [http://tools.ietf.org/html/rfc7469 RFC7469].
HPKP is an '''experimental''' HTTP header sent by a server to a client, to indicate that some certificates related to the site should be pinned in the client. The client would thus refuse to establish a connection to the server if the pining does not comply.
-Due to its experimental nature, HPKP is currently '''not''' recommended on production sites. More informations can be found on the [[https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning MDN description page]].
+Due to its experimental nature, HPKP is currently '''not''' recommended on production sites. More informations can be found on the [https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning MDN description page].
= Recommended Server Configurations =