ioerror / duraconf Goto Github PK

While still a draft, HTTP-Servers could contain sample Key Pinning configurations. Maybe a tutorial would make sense too.

http://tools.ietf.org/html/draft-ietf-websec-key-pinning-12

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?

As described in https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

the mitigations includes

1. Open gpg.conf in a text editor. Ensure there is no line starting with keyserver.
   If there is, remove it.
2. Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org
   to the end of it.

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.

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.

https://github.com/ioerror/duraconf/tree/master/startssl the images are all 404

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

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

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.

e.g. from from https://stribika.github.io/2015/01/04/secure-secure-shell.html

on line 77 of current file, the comment for option personal-cipher-preferences mentions "digest preferences" whereas it should be "cipher preferences".

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.

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?

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/

I'd really like to see #39 and #40 getting merged, but they aren't yet. Do you still maintain this repo?

The comments here:

are not consistent with the conf options (digest vs cipher in different parts of the comments).

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.

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.

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.