I added a new theory section in SSL covering HTTP Public Key Pinning (HPKP)
plus added the corresponding Apache-Config.
https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/113
Feedback is welcome.
(It's my first contribution to the BetterCrypto-Guide and I'm not so
fluent in LaTex, hop
Hi,
Austrian "Communications Authority" (Rundfunk und Telekom
Regulierungs-GmbH) invites to a Workshop "E-Mail-Security, What
providers can contribute" this week (5th November, in Vienna).
See Website: https://www.rtr.at/de/inf/E_Mail_Sicherheit05112015
As I spent the last weekends figuring out h
Sebastian analyzed my used CipherString for Apache in my Paper, and it's
not the originally Bettercrypto-Cipherstring.
we are talking about this (comparison):
https://it-sec.ovh/doc/myCipherstring-versus-BetterCrypto.png
Am 02.11.2015 um 17:59 schrieb Sebastian:
> en: "the faster ECDHE variants
Am 2015-11-03 00:38, schrieb Aaron Zauner:
Nevertheless I feel the same way, AES128 should be preferred;
and that exactly what we're doing with the latest version of
our bettercrypto cipherstring recommendation:
https://git.bettercrypto.org/ach-master.git/blob/HEAD:/src/common/cipherStringB.tex
Azet:
Nevertheless I feel the same way, AES128 should be preferred;
and that exactly what we're doing with the latest version of
our bettercrypto cipherstring recommendation:
https://git.bettercrypto.org/ach-master.git/blob/HEAD:/src/common/cipherStringB.tex
The current recommendation for Apa
Am 2015-11-03 10:23, schrieb Aaron Zauner:
Which OpenSSL version are you testing with?
Tested on OpenSSL 1.0.1k 8 Jan 2015 on Debian 8.2 Jessie:
https://git.bettercrypto.org/ach-master.git/blob/HEAD:/unsorted/ssl/OpenSSL_Ciphers_Debian_8.2_Jessie.txt
_
Am 03.11.2015 um 12:39 schrieb Aaron Zauner:
> The problem with these cipherstrings is that
> they're interpreted differently depending on the OpenSSL branch and
> version.
Is this true?
I think the String just works syntactically correct as designed.
Lets have a look at the current cipherString-
Am 03.11.2015 um 21:41 schrieb Terje Elde:
> ... Camellia
> For systems I might not be responsible for in 5 years, I'd rather leave it in.
Could be a good decision or not, depending on how things come.
Maybe Camellia turns out to be broken earlier than AES. Then you have to
touch the systems
Am 03.11.2015 um 22:38 schrieb Aaron Zauner:
> I recommend double-checking a cipherstring recommendation against
> *all* 0.9.8 and 1.0.1 branches.
OK ... thats harder than I expected.
But than it seems to be unsolvable for me to get a predictable situation
by recommending a fixed "Cipher Suite B"
I just updated my document (https://it-sec.ovh/secure-mail ).
All planned content is now covered.
Feedback is still highly welcome.
regards,
Gunnar
Am 01.11.2015 um 12:21 schrieb Gunnar Haslinger:
> As I spent the last weekends figuring out how DNSSec, BIND, Postfix ...
> work togeth
lob/HEAD:/src/common/cipherStringB.tex
On 2015-11-03 07:57 Gunnar Haslinger wrote:
> CipherString-B in Theory-Section 3.2.3 is different to
Apache-Recommendation in Section 2.1.1.
On 2015-11-03 08:04 L. Aaron Kaplan wrote:
> This sounds like a mistake then. They should be the same.
I just c
Am 07.11.2015 um 15:23 schrieb L. Aaron Kaplan:
>> Should Apache, Dovecot, nginx, lighttp, etc... CipherStrings be changed
>> to match CipherString-B?
>>
> Yes. See above.
OK, did this for Webservers and Mailservers
https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/117
___
To continue the CipherString-B Discussion:
I try to sum up some thoughts:
1) The Ciphers in current CipherString-B are sane but not ideally sorted
on all Versions of OpenSSL.
2) Camellia could be considered to be removed.
3) Performance: ECDHE could be prefered over DHE
4) Performance: AES128 coul
Am 07.11.2015 um 20:40 schrieb Gunnar Haslinger:
> To continue the CipherString-B Discussion:
>
> ...
> the Result is:
> $ openssl ciphers -v
> '-ALL:ECDH+aRSA+AES:DH+aRSA+AES:aRSA+kRSA+AES:+AES256' | cut -f1 -d" "
> ECDHE-RSA-AES128-GCM-SHA256
> EC
Am 08.11.2015 um 11:46 schrieb Adi Kriegisch:
>> the Result is:
>> $ openssl ciphers -v
>> '-ALL:ECDH+aRSA+AES:DH+aRSA+AES:aRSA+kRSA+AES:+AES256' | cut -f1 -d" "
>> ECDHE-RSA-AES128-GCM-SHA256
>> ECDHE-RSA-AES128-SHA256
>> ECDHE-RSA-AES128-SHA
>> DHE-RSA-AES128-GCM-SHA256
>> DHE-RSA-AES128-SHA256
>
Am 08.11.2015 um 12:15 schrieb Adi Kriegisch:
> Supporting non-ephemeral ciphers is only ever required on certain
> versions of openssl 0.9.8
> In other words: you need not provide AES*GCM-SHA2 and AES*SHA2.
I tested on Debian Lenny 6 with OpenSSL 0.9.8o, it has no SHA2 support,
so I decided to
Am 08.11.2015 um 12:48 schrieb Adi Kriegisch:
> The other way around: you *only* need SHA1 support. All newer
> implementations are well aware of ECDHE and DHE and thus will choose
> ephemeral ciphers anyways.
Ah - OK, sorry I just misunderstood your former mail.
> Actually I wouldn't do that too
Am 08.11.2015 um 14:09 schrieb Adi Kriegisch:
> or on pretty old openssl 0.9.8:
> ECDHE-RSA-AES256-SHA
> ECDHE-RSA-AES128-SHA
> ECDH-RSA-AES256-SHA
> ECDH-RSA-AES128-SHA
> DHE-RSA-AES256-SHA
> AES256-SHA
> DHE-RSA-AES128-SHA
> AES128-SHA
What 0.9.8 Version was capable of ECDH? Mine is not, and the
Am 08.11.2015 um 15:33 schrieb Adi Kriegisch:
> No. Stop here: I was not discussing Cipherstring-B with you but tried to
> support you in finding a cipher string that fits your requirements
OK
My personal requirements for the Demo-Setup are already met.
I started this thread with "To continue the
> https://www.m3aawg.org/sites/default/files/m3aawg-forward-secrecy-recommendations-2016-01.pdf
>
Your guide says "Generate certs such as ..." => but you describe how to
generate DH-Parameters, not certs.
And there is no option "smtpd_tls_4096_param_file" in Postfix.
see the documentation here:
Am 03.03.2016 um 18:38 schrieb Pepi Zawodsky:
Can anyone tell me, if :+SSLv3: really should be there?
I totally agree that this notation is counter-intuitive. Yet, Sebastian is
totally right. This enables Cipher suites _defined_ in the SSLv3 spec (which
are used in TLS 1.0 and above as well) b
NIST is currently working on an Updated Publication:
SECOND DRAFT
NIST Special Publication 800-177
Trustworthy Email
http://csrc.nist.gov/publications/drafts/800-177/sp800-177_second-draft.pdf
The public comment period closes April 29th, 2016.
Email comments to sp800-...@nist.gov
Details: http
Hey Guillaumbe,
Am 2016-10-14 12:16, schrieb Guillaume REMBERT:
> What is missing here is that by default in a "TLS may" aka
> opportunistic configuration, the ciphers used are driven by the
> parameter "smtpd_tls_ciphers", wich is defined by default to medium
Thats right and it is a well discu
Am 2016-10-14 12:49, schrieb Guillaume REMBERT:
> For MTA, the advice is "better to keep poor encryption than
> nothing". I am fine with this, BUT part of the config indicated is then
> useless (and made me feel like I did something incorrect), isn'it?
> These 2 parameters are not used at all with
Full-Quote of Guillaume's mail see below (mail was sent directly and
didn't go to the list).
My Opinion about this: Yes, you have to use dedicated submission-ports,
that's how it is defined to work. Misusing port 25 is a wideseen
configuration, but that's not how it was designed in the RFC's. You
Am 28.11.2016 um 23:04 schrieb L. Aaron Kaplan:
> I did not notice that when I re-issued the certificate.
AFAIR the Warning is there since end of october, after Login at
https://startssl.com at the bottom of the page they display it in red:
Notice:
Mozilla and Google decided to distrust all Start
Am 30.11.2016 um 21:57 schrieb sivmu:
> when pinning your certificates you can include one whose
> coresponding key is not on the machine but acts as the backup key, maybe
> even offline.
Not "can", its not an option it is mandatory!
The browsers will NOT accept HPKP pinning if you don't add an c
Just in case somebody finds it useful:
I supervise all my certificates I'm using on my Webserver with a little
Perl-Scripts I wrote.
Sourcecode see here: http://pastebin.com/FpjRqq4t
three Variables to configure:
$limit = 30;
$LetsEncrytpCertDir="/etc/letsencrypt/live";
$ApacheConfigs="/etc/apa
Am 2017-03-08 16:32, schrieb Hanno Böck:
This is one of the reasons why these days I tend to advise against HPKP
with the exception of high risk sites. There's just far too much that
can go wrong with HPKP.
Several possibilities to handle this risk:
Use Let's Encrypt with your custom CSR, recy
Am 2017-03-08 17:06, schrieb Hanno Böck:
I'd say then you're trading one security property for another.
I agree...
but: Before we used Let's Encrypt, we were pretty happy using
certificates valid for 1 or 2 years. I didn't say: use the keypair
forever - but changing it every ~60 days is a bi
Regarding using Let's Encrypt with TLSA/DANE and HPKP:
I wrote a short Blog-entry about using Let's encrypt with CSRs - keeping
the RSA-Keypair when renewing the certificate.
maybe somebody finds this helpful (in German):
https://hitco.at/blog/lets-encrypt-csr/
As keeping the RSA-Keypair when r
Am 2017-03-17 09:32, schrieb Aaron Zauner:
Maybe I misunderstand, but why would you want to do that? You can do
a key-rollover just fine with HPKP headers and TLSA records.
Sure, but that needs time and a solid understanding of HPKP and/or TLSA
for preparing a new Keypair (and/or new Backup-
Am 2017-03-17 10:24, schrieb Hanno Böck:
HPKP is a nice feature, but it absolutely requires a solid
understanding and a good plan to avoid its pitfalls. If you're not
capable of having a good keyrolover plan then you shouldn't deploy
HPKP.
I already agreed to this before.
But you still req
Am 2017-03-17 10:24, schrieb Hanno Böck:
HPKP is a nice feature, but it absolutely requires a solid
understanding and a good plan to avoid its pitfalls. If you're not
capable of having a good keyrolover plan then you shouldn't deploy
HPKP.
I already agreed to this before.
But you still req
34 matches
Mail list logo
