ioerror / duraconf Goto Github PK
View Code? Open in Web Editor NEWduraconf - A collection of hardened configuration files for SSL/TLS services
Home Page: http://www.appelbaum.net/
duraconf - A collection of hardened configuration files for SSL/TLS services
Home Page: http://www.appelbaum.net/
duraconf - A collection of hardened configuration files for SSL/TLS services Hopefully this will help you make a more informed choice about what cipher list should be used for different applications. What you find here are recommended configurations, you should seriously consider using these, but you have to make some choices. When you pick a cipher list, you have a couple different options of how you go about it: 1. make a very specific declaration of what is acceptable. This has the advantage of being able to define very closely of what you want, but the disadvantage of having to stay on top of the latest crypto advancements, with every crypto library upgrade. 2. make a general declaration of which cipher list to use. this has the advantage of allowing you to rely on your crypto libraries to make (hopefully) informed choices for you (and to deactivate known bad/weak/recently broken) ciphers while you don't have the burden of ensuring that they are always resulting in a good cipher suite. The disadvantage is that you cannot fine tune what exactly you get in return. 3. A mixture of being specific and letting your crypto library decide from general statements. This can be useful if, for example, you find out that some particular crypto has become too weak, for example you might use a generic list but then exclude MD5, because your crypto libraries haven't removed that yet. 4. Decide on a threat model for possible attacks that may expose an important private key. Ciphers are often offered in a mode that provides Perfect Forward Secrecy. While there are performance considerations, if you run a high security operation where traffic disclosure would be a serious problem, it is an important property to consider. Generally it seems safer to have the crypto library take the bulk of the decision since it should be for the most part fire-and-forget, while the other options require that you always stay up to date on things and tweak as needed. For practical use, and for people who can afford to follow crypto news, a mixture of both is surely a good idea. So start with the general cipher list and when you become aware that something is bad then just add this specific part to your otherwise general cipher list until the crypto library defaults get updated to fix that. Unfortunately, its not possible to come up with one cipher configuration that is going to work for all configurations. There are many different programs that implement different versions of libraries that have different ciphers available. In fact, a different versions of the same program may be linked against different libraries which have different ciphers available. An important configuration issue for service operators and users is understanding Perfect Forward Secrecy. Generally, PFS sessions are computationally more expensive than connections without PFS properties. It is extremely important to remember that using SSL and/or TLS does not ensure that your traffic is encrypted for all time. Generally, SSL/TLS services offer two general modes of operation - one mode is ephemerally keyed and the other is not. A TLS server that only offers AES256-SHA is strong against an attacker who will never recover the secret key used by the server and cannot break AES256. However, if an attacker is able to recover the server's key, the attacker will be able to retroactively decrypt all traffic that has been recorded where the AES256-SHA cipher was used. If that same server uses an ephemeral cipher such as DHE-RSA-AES256-SHA, the attacker cannot recover previous encrypted sesssions without breaking RSA and/or AES256 for *each* session. In both cases, when the attacker has the private key, all future communications with the server are unsafe. Clients generally deal with this by looking up a revokation list or by using something like the OCSP. Realistically, they're in a lot of trouble and that kind of trouble is out of scope. If you're in doubt it's probably a reasonable thing to use DHE or EDH modes unless you have load issues. The cipher lists you will find here actually vary depending on which version of the crypto library that you have. For example, if you were to find this list recommended: HIGH:MEDIUM:!aNULL:!SSLv3:!SSLv2:!MD5:@STRENGTH In openssl version 1.0.1e this will mean the following list of ciphers: $ openssl ciphers -v 'HIGH:MEDIUM:!aNULL:!SSLv3:!SSLv2:!MD5:@STRENGTH' ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 It is also worth noting that this is setting a policy, and your site may have different policies, depending on your intended audience. There are many questions to consider in determining a policy. For example, in the worst case, when a client doesn't support the higher strength ciphers my server supports, do I want to keep up the image that medium strength ciphers are secure enough in my specific use case, environment and opponents? Or should I not allow anything but the highest strength ciphers, and those clients that do not support them are just denied? Its likely that in many cases there is no possibility of making it clear to the user that their setup does not allow for secure use of your services, and what their options are. I _think_, at least with apache, it should be possible to redirect users whose setup doesn't provide a compatible cipher suite, to an informational web page which explains further steps they can and should take (i have no idea how).. Unfortunately, in most cases, users will not get any message at all and they will have no clue why they are shut out. This could result in unhappy users with no idea of where to turn, and potentially a higher support burden. Notes on format of cipher designations -------------------------------------- Format of cipher designations differ, but in general they follow the format described in ciphers(5). A few notes: The order specified is the preference order, and the list is separated by colons. The list can be specific ciphers (eg. RC4-SHA), a list of suites containing a certain algorith (SHA1), or a cipher suite of a certain type (TLSv1). There are also cipher strings which are a grouping of different ciphers into a specific category (eg. HIGH). When removing ciphers that you do not want, you have a choice between indicating ! or -, the difference is subtle but important. It's good practice to use ! if you really do not want this class to ever get used, and to use - when you want to allow them to be still used if you later added something to your existing cipher list. Finally, there is also the @STRENGTH parameter, which sorts the cipher list in order of encryption algorithm key length. Suggested reading ----------------- https://www.eff.org/pages/how-deploy-https-correctly
shown when try to encrypt/decrypt text message
$ uname -a
Linux mx1 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
duraconf/configs/gnupg/gpg.conf
Lines 57 to 58 in 04f992c
While still a draft, HTTP-Servers could contain sample Key Pinning configurations. Maybe a tutorial would make sense too.
More information about the Logjam attack here: https://weakdh.org/
And here are some information what to do as a server admin: https://weakdh.org/sysadmin.html
on line 77 of current file, the comment for option personal-cipher-preferences mentions "digest preferences" whereas it should be "cipher preferences".
Seems gnupg 2.1 now uses dirmngr.conf according to https://sks-keyservers.net/overview-of-pools.php. I haven't managed to get the new configuration to work yet but wanted to point it out.
I discovered that this line in the nginx file prevents Internet Explorer 9 and earlier from connecting to the server:
ssl_ciphers ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA;
It seems to actually work in IE 10. But in IE 8 and 9 it returns the error "This program cannot display the webpage." Commenting out that line fixes the issue, but of course allows older and possibly insecure ciphers to be used.
Maybe add require-cross-certification
to the gpg.conf?
It is the default in Debian AFAIK with this reason given:
# When verifying a signature made from a subkey, ensure that the cross
# certification "back signature" on the subkey is present and valid.
# This protects against a subtle attack against subkeys that can sign.
# Defaults to --no-require-cross-certification. However for new
# installations it should be enabled.
As described in https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
the mitigations includes
gpg.conf
in a text editor. Ensure there is no line starting with keyserver
.dirmngr.conf
in a text editor. Add the line keyserver hkps://keys.openpgp.org
So at the very least, the gpg.conf
file needs reviewing. I'm looking for a good known configuration with sane defaults, came up empty so far.
When I used the ciphers listed in the nginx example, and ran the Qualys SSL server test, I was informed that it was vulnerable to BEAST.
I've used ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
instead.
Hi,
I just read this article in the EFF website and wondered if maybe the different configurations here must be updated.
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH
https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/
Hi,
I have a question about following line in the gpg.conf:
personal-cipher-preferences AES256 AES192 AES CAST5
Why not also add the Twofish cipher?
I'm wondering if someone has researched node's TLS module yet.
From my limited testing, it looks a bit dire as PFS doesn't seem achievable without the support of ECDHE ciphers (though't I'm by no means an expert on cipher suites).
Here are the docs.
The comments here:
duraconf/configs/gnupg/gpg.conf
Lines 77 to 83 in 3f0d977
are not consistent with the conf options (digest vs cipher in different parts of the comments).
https://github.com/ioerror/duraconf/tree/master/startssl the images are all 404
In particular, this comment on HSTS could be misinterpreted: "This configuation does not include the HSTS header to ensure that users do not accidentally connect to an insecure HTTP service after their first visit."
The reader could understand this to mean that the HSTS header is omitted on purpose, and that the omission ensures that users do not accidentally connect insecurely.
I think you probably meant "This configuration does not include the HSTS header, which would ensure that users do not accidentally connect to an insecure HTTP service after their first visit."
Incidentally, should the example include HSTS?
Config has:
ssl_protocols SSLv3 TLSv1;
I would remove SSLv3
The README suggests it is possible to have Apache redirect users with insufficiently secure SSL/TLS stacks to some specific page indicating the problem.
http://httpd.apache.org/docs/current/mod/mod_ssl.html#envvars describes the SSL related environmental variables that could be used as part of a RewriteCond
and RewriteRule
(http://httpd.apache.org/docs/current/mod/mod_rewrite.html) to redirect users based on their SSL capabilities.
The RewriteRule would look something like:
RewriteCond %{SSL:SSL_CIPHER_USEKEYSIZE} < 256
RewriteRule /* http://some/error/page [L,R=302]
This will only work if Apache is set to allow the lesser cipher strengths in its SSL configuration, then use this redirect to point the user elsewhere. Since the user has already transmitted their request data at this point, it is too late in the request to realistically protect anything about the request (session cookies, authentication data).
If one is really concerned about allowing use of lower strength ciphers then this isn't going to work very well, and they should be omitted from the SSL configuration. This will of course cause a SSL handshake error for some clients.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.