[IMC-Tech] Help with Cacert multiple domains config
mat(a)riseup.net
mat at riseup.net
Fri Jan 6 08:00:37 PST 2006
So, wich line do you recomend to include in http.conf ?
Example ?
Mat
> -----Mensaje original-----
> De: imc-tech-bounces at lists.indymedia.org
> [mailto:imc-tech-bounces at lists.indymedia.org] En nombre de
> xmux at riseup.net
> Enviado el: Jueves, 05 de Enero de 2006 17:16
> Para: imc-tech at lists.indymedia.org
> Asunto: Re: [IMC-Tech] Help with Cacert multiple domains config
>
> WARNING: LONG....BORING.....
>
> On Wed, Jan 04, 2006 at 07:10:56PM +0000, Chris wrote:
> >
> > I have added an example to the wiki:
> >
> >
> >
> https://docs.indymedia.org/view/Sysadmin/CaCertSsl#httpd_conf_example
> >
> > Shout if it needs more comments etc...
> >
> > The SSLCipherSuite line could perhaps be better, I have
> copied it from
> > another server, not sure what I got it from originally...
>
> The SSLCipherSuite line looks like nonsense to me. I'll
> break it down for people that may not be familiar with the
> format and comment on each part.
>
> ALL:!ADH:!EXPORT56:!RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv2:+EXP:+eNULL
>
> The modifier characters work like this:
>
> 'CIPHERS'
>
> With no character, the set of ciphers specified by CIPHERS is
> explicitly added
>
> '!CIPHERS'
>
> Permanently remove the set of ciphers. They cannot later be
> explicitly added again either as a group or individially.
>
> '-CIPHERS'
>
> Remove the set of ciphers. Like above but you can add them
> again by specifying them explicitly.
>
> '+CIPHERS'
>
> Move the set of ciphers to the end of the list. Does not
> mean 'add to list'. That's what 'CIPHERS' without any
> modifier character is for.
>
> Full details in ciphers(1) manpage
>
> So.......
>
>
> ALL
>
> Begin with the complete set of ciphers (This is the usual
> way to start out)
>
> !ADH
>
> Remove all ciphersuites that use anonymous diffie-hellman
> key exchange.
> This is a good idea because this key exchange is not
> authenticated with
> certificates and can not protect against active attacks.
>
> !EXPORT56
>
> This removes all symmetric ciphers (the ones that are
> actually used to
> encrypt data) that have been weakened to use 56 bit keys.
> This doesn't
> include DES which normally uses a 56 bit key (use LOW
> keyword for that)
> or the much weaker 40 bit export weakened ciphers (EXPORT40
> to remove
> those).
>
> !RC4+RSA
>
> Remove the RC4 symmetric algorithm when used with RSA key exchange.
> Why? Who knows.
>
> +HIGH
>
> Move the symmetric ciphers with the strongest (more that
> 128 bits) keys
> to the end of the list!!?!
>
> !MEDIUM
>
> Remove symmetric ciphers with 128 bit keys. I don't know
> why you would
> want to do this. 128 bit keys are pretty long and nobody
> is ever going
> to be able to crack them without using science fiction
> technology (like
> DNA or quantum computers) that can break keys of any length.
>
> !LOW
>
> Remove symmetric ciphers with 64 and 56 bit keys like old school DES
> for example, but not including the specially weakened
> export ciphers.
>
> !SSLv2
>
> Disable SSL version 2.0. Good idea, SSL 2.0 has many cryptographic
> weaknesses the worst of which is that it can easily be
> tricked into using
> weak ciphers by an active attacker.
>
> +EXP
>
> Move the export weakened ciphers to the end of the list.
> Good thing this
> is here or else the strongest ciphers would still be at the
> end of the
> list and the server would be configured to prefer to use
> ciphers with
> easily crackable 40 bit keys. Happy accident it seems.
>
> +eNULL
>
> This doesn't do anything because the NULL ciphersuite
> (which doesn't use
> any encyption at all!) is not included in the set of 'ALL' ciphers
> because it is mostly just for testing. If it had been
> included in ALL
> then the server would now be configured to use no encryption at all
> whenever possible! That's because all of the other ciphers
> have either
> been removed or moved to the end of the list.
>
>
> So here's what we're left with:
>
> $ openssl ciphers -v
> 'ALL:!ADH:!EXPORT56:!RC4+RSA:+HIGH:!MEDIUM:!LOW:!SSLv2:+EXP:+eNULL'
> DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA
> Enc=AES(256) Mac=SHA1
> DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS
> Enc=AES(256) Mac=SHA1
> AES256-SHA SSLv3 Kx=RSA Au=RSA
> Enc=AES(256) Mac=SHA1
> EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA
> Enc=3DES(168) Mac=SHA1
> EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS
> Enc=3DES(168) Mac=SHA1
> DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA
> Enc=3DES(168) Mac=SHA1
> EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40)
> Mac=SHA1 export
> EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40)
> Mac=SHA1 export
> EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40)
> Mac=SHA1 export
> EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40)
> Mac=MD5 export
>
>
> This is the list of cipher sets that the server will support
> and the order in
> which it prefers to use them.
>
> >From this list, there are three sets of symmetric ciphers
> left that we support:
>
> AES, 3DES, and export weakened ciphers with 40 bit keys.
>
> AES may not be well supported because it is only specified
> for TLS 1.0 (not
> SSL 3.0 or 2.0) and was not even in the TLS standard at all.
> It wasn't added
> until 2002 (rfc 3268).
>
> 3DES is supported by everything but it is really slow and is
> even weaker than
> the 128 bit ciphers that you have already excluded. Although
> it has a 168 bit
> key, it is brute forceable as if it had a 112 bit key
> (meet-in-the-middle attack).
> This is all academic though because nobody can brute force
> 112 bit keys either.
>
> Then there are the export ciphers. At least you can talk to
> export weakened clients
> which is the whole purpose of the export ciphers in the first
> place. I don't know
> if including these is a good idea or not but at least they
> should be at the end of
> the list (which they are).
>
> I wish I could give you some advice about what would be a
> better list of ciphersuites
> to support but I'm right in the middle of some research to
> answer that exact question.
>
> Stay tuned....
>
>
> -xmux
>
> _______________________________________________
> imc-tech mailing list
> imc-tech at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-tech
>
More information about the imc-tech
mailing list