Re: Improving SSL config
On 18.11.2011 18:47, Rainer Jung wrote: > Fine with me. Current SSLCipherSuite for 2.2 definitely needs > improvement and latest 2.4 should be the way to go. > > Except: Since SSLv2 is still available for 2.2, the -SSLv2 is needed in > the cipher list. > > Please feel free to go ahead an remove my proposal. Ok, done (r1203962). There's no need to have -SSLv2 in SSLCipherSuite, because "!MD5" will already blow away all those ciphers (SSLv2 only uses MD5). What makes sense, OTOH, is adding "SSLProtocol all -SSLv2" to the 2.2.x config - this makes sure that SSLv2 isn't used even if an admin later changes the cipher list and "accidentally" reintroduces SSLv2 ciphers. Kaspar
Re: Improving SSL config
On Fri, Nov 18, 2011 at 10:05 PM, Stefan Fritsch wrote: > On Friday 18 November 2011, Kaspar Brand wrote: >> "all" simply stands for "+SSLv3 +TLSv1", >> so we might just leave the default config as is - i.e., not have >> any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf. > > We may have "TLSv1.1" "and TLSv1.2" in the future. Changing the > default config to an explicit list is bound to cause problems. +1 for > keeping "all". was concerned about this as well.
Re: Improving SSL config
On Friday 18 November 2011, Kaspar Brand wrote: > "all" simply stands for "+SSLv3 +TLSv1", > so we might just leave the default config as is - i.e., not have > any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf. We may have "TLSv1.1" "and TLSv1.2" in the future. Changing the default config to an explicit list is bound to cause problems. +1 for keeping "all".
Re: Improving SSL config
On 18.11.2011 18:20, Kaspar Brand wrote: On 18.11.2011 13:09, Rainer Jung wrote: You might want to drop the -SSLv2 from our SSLCipherSuite in docs/conf/extra/httpd-ssl.conf.in then as well. You're right, yes. As there were no objections to the changes I proposed on the list a few days ago, I now committed them with r1203752/r1203753. If you generally agree with these modifications, I could also prepare and propose a backport for 2.2.x (there's currently an earlier one from you in 2.2.x's STATUS). Just let me know. Fine with me. Current SSLCipherSuite for 2.2 definitely needs improvement and latest 2.4 should be the way to go. Except: Since SSLv2 is still available for 2.2, the -SSLv2 is needed in the cipher list. Please feel free to go ahead an remove my proposal. Regards, Rainer
Re: Improving SSL config
On 18.11.2011 13:09, Rainer Jung wrote: > You might want to drop the -SSLv2 from our SSLCipherSuite in > docs/conf/extra/httpd-ssl.conf.in then as well. You're right, yes. As there were no objections to the changes I proposed on the list a few days ago, I now committed them with r1203752/r1203753. If you generally agree with these modifications, I could also prepare and propose a backport for 2.2.x (there's currently an earlier one from you in 2.2.x's STATUS). Just let me know. Kaspar
Re: Improving SSL config
On 18.11.2011 06:32, Kaspar Brand wrote: As I can't think of any good reason why a new major version of an HTTPS server released in late 2011 should still support insecure SSL protocol cruft from the 1990s (v2 was superseded about 15 years ago, when SSLv3 was introduced), I went for the first option and completely dropped SSLv2 support with r1203491/r1203495 in trunk and 2.4, respectively. For the SSLProtocol directive, specifying "-SSLv2" is still permitted, but basically just for backward compatibility with the relatively popular "SSLProtocol all -SSLv2" incantation (technically, the code simply ignores "-SSLv2", as it is now always forced to off). You might want to drop the -SSLv2 from our SSLCipherSuite in docs/conf/extra/httpd-ssl.conf.in then as well. Rainer
Re: Improving SSL config
On 17.11.2011 13:18, Nick Gearls wrote: > Isn't it safer to only accept explicit entries, like > > SSLCipherSuite -ALL:RC4-SHA:AES128-SHA:TLSv1+HIGH:SSLv3+HIGH:-aNULL > SSLProtocol-ALL +SSLv3 +TLSv1 It depends on the directive. For SSLCipherSuite, the string is just passed verbatim to SSL_CTX_set_cipher_list(), so it's OpenSSL's behavior which is relevant. In this case, saying "-ALL:HIGH" is the same as saying "HIGH" only. SSLProtocol, on the other hand, is handled by mod_ssl itself, and if you want to turn on multiple protocols with "+" (instead of just configuring a single one, like "SSLProtocol TLSv1"), then that's indeed a valid reason for starting with "-all". But now, after having dropped SSLv2 support in r1203491/r1203495, "all" simply stands for "+SSLv3 +TLSv1", so we might just leave the default config as is - i.e., not have any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf. Kaspar
Re: Improving SSL config
On 15.11.2011 19:48, Philip M. Gollucci wrote: > On 11/14/11 17:41, Kaspar Brand wrote: >> On 14.11.2011 15:46, William A. Rowe Jr. wrote: >>> Isn't it similarly time to deploy SSLProtocol -SSLv2 by default? >> >> Oh yes, definitely. I didn't realize that "all" is still the default for >> SSLProtocol... for trunk and 2.4, I would suggest to change the defaults >> in the code. In decreasing order of preference: >> >> - completely drop SSLv2 support >> >> - change the default (in modssl_ctx_init) to >> SSL_PROTOCOL_ALL & ~SSL_PROTOCOL_SSLV2 >> >> The first option also means that we would "comply" with RFC 6176 (in >> case someone complains about mod_ssl dropping support for a clearly >> outdated and insecure protocol). >> >> Kaspar >> > > SSLProtocol -ALL +SSLv3 +TLSv1 > SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP > > Is the PCI compliant line should we change it, it should be to this. The PCI DSS requirements aren't that specific on protocol or cipher selection, actually (at least not in v2.0 - unless I'm completely missing something in that document). As I can't think of any good reason why a new major version of an HTTPS server released in late 2011 should still support insecure SSL protocol cruft from the 1990s (v2 was superseded about 15 years ago, when SSLv3 was introduced), I went for the first option and completely dropped SSLv2 support with r1203491/r1203495 in trunk and 2.4, respectively. For the SSLProtocol directive, specifying "-SSLv2" is still permitted, but basically just for backward compatibility with the relatively popular "SSLProtocol all -SSLv2" incantation (technically, the code simply ignores "-SSLv2", as it is now always forced to off). Kaspar
Re: Improving SSL config
Isn't it safer to only accept explicit entries, like SSLCipherSuite -ALL:RC4-SHA:AES128-SHA:TLSv1+HIGH:SSLv3+HIGH:-aNULL SSLProtocol-ALL +SSLv3 +TLSv1 Nick On 13/11/2011 11:47, Kaspar Brand wrote: On 07.10.2011 07:10, William A. Rowe Jr. wrote: Exactly... we should default to a server with a preference for cryptographic strength, but I have no objection to offering a commented-out, clearly documented 'alternative' configuration favoring performance, provided that is clearly labeled as 'not for sensitive data'. Now that the dust after the "BEAST" bang has settled somewhat (and it's clear that it needs to / will be fixed on the client side [1][2][3]), I think it's a good time to revisit the default setting for SSLCipherSuite - at least for trunk and 2.4. My proposal is something like the attached patch - thoughts, objections? Kaspar [1] https://bugzilla.mozilla.org/show_bug.cgi?id=665814 [2] http://codereview.chromium.org/7621002/ [3] http://my.opera.com/securitygroup/blog/2011/09/28/the-beast-ssl-tls-issue
Re: Improving SSL config
- Original Message - > On 14.11.2011 15:46, William A. Rowe Jr. wrote: > > Isn't it similarly time to deploy SSLProtocol -SSLv2 by default? > > Oh yes, definitely. I didn't realize that "all" is still the default > for > SSLProtocol... for trunk and 2.4, I would suggest to change the > defaults > in the code. In decreasing order of preference: > > - completely drop SSLv2 support > > - change the default (in modssl_ctx_init) to > SSL_PROTOCOL_ALL & ~SSL_PROTOCOL_SSLV2 +1 > The first option also means that we would "comply" with RFC 6176 (in > case someone complains about mod_ssl dropping support for a clearly > outdated and insecure protocol). > > Kaspar > -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Improving SSL config
On 14.11.2011 15:46, William A. Rowe Jr. wrote: > Isn't it similarly time to deploy SSLProtocol -SSLv2 by default? Oh yes, definitely. I didn't realize that "all" is still the default for SSLProtocol... for trunk and 2.4, I would suggest to change the defaults in the code. In decreasing order of preference: - completely drop SSLv2 support - change the default (in modssl_ctx_init) to SSL_PROTOCOL_ALL & ~SSL_PROTOCOL_SSLV2 The first option also means that we would "comply" with RFC 6176 (in case someone complains about mod_ssl dropping support for a clearly outdated and insecure protocol). Kaspar
Re: Improving SSL config
On 11/13/2011 4:47 AM, Kaspar Brand wrote: My proposal is something like the attached patch - thoughts, objections? Reviewing the suggested list. The commentary looks good. Isn't it similarly time to deploy SSLProtocol -SSLv2 by default?
Re: Improving SSL config
On 07.10.2011 07:10, William A. Rowe Jr. wrote: > Exactly... we should default to a server with a preference for cryptographic > strength, but I have no objection to offering a commented-out, clearly > documented 'alternative' configuration favoring performance, provided that > is clearly labeled as 'not for sensitive data'. Now that the dust after the "BEAST" bang has settled somewhat (and it's clear that it needs to / will be fixed on the client side [1][2][3]), I think it's a good time to revisit the default setting for SSLCipherSuite - at least for trunk and 2.4. My proposal is something like the attached patch - thoughts, objections? Kaspar [1] https://bugzilla.mozilla.org/show_bug.cgi?id=665814 [2] http://codereview.chromium.org/7621002/ [3] http://my.opera.com/securitygroup/blog/2011/09/28/the-beast-ssl-tls-issue Index: docs/conf/extra/httpd-ssl.conf.in === --- docs/conf/extra/httpd-ssl.conf.in (revision 1201408) +++ docs/conf/extra/httpd-ssl.conf.in (working copy) @@ -48,12 +48,19 @@ # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. -SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL +SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 -# SSL Cipher Honor Order: -# On a busy HTTPS server you may want to enable this directive -# to force clients to use one of the faster ciphers like RC4-SHA -# or AES128-SHA in the order defined by SSLCipherSuite. +# Speed-optimized SSL Cipher configuration: +# If speed is your main concern (on busy HTTPS servers e.g.), +# you might want to force clients to specific, performance- +# optimized ciphers. In this case, prepend those ciphers +# to the SSLCipherSuite list, and enable SSLHonorCipherOrder. +# Caveat: by giving precedence to RC4-SHA and AES128-SHA +# (as in the example below), most connections will no longer +# have perfect forward secrecy - if the server's key is +# compromised, captures of past or future traffic must be +# considered compromised, too. +#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5 #SSLHonorCipherOrder on # Pass Phrase Dialog:
Re: Improving SSL config
On 10/7/2011 12:05 AM, Kaspar Brand wrote: > On 06.10.2011 10:58, Rainer Jung wrote: >> On 02.10.2011 09:07, William A. Rowe Jr. wrote: >>> -1 in this respect; faster is not more secure. We must default to setting >>> the strictest cipher choices, with a commented-out "this is faster, but far >>> less secure" alternative for those with less targeted assets. >>> >>> If someone is enabling mod_ssl, it is to secure their traffic, not to speed >>> up their server. >>> >>> And no, MD4, although immune to *this* vector, is simply not preferable. >> >> Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. >> So there is a need to improve. My suggestion is a straight backport from >> trunk. >> >> So what is the "strictest cipher choice" you suggest? > > Assuming s/MD4/RC4/ in Bill's message, it seems that > > SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 > > would be more appropriate for mod_ssl's default config. > > I agree that the current SSLCipherSuite default in 2.2.x should be > improved (yes, right now it even includes suites with 40-bit > encryption!), but giving specific precedence to RC4-SHA and AES128-SHA > doesn't really feel right for a default config file. [1] > > Kaspar > > [1] in trunk, the SSLCipherSuite change in r966160 was inspired by > http://journal.paul.querna.org/articles/2010/07/10/overclocking-mod_ssl/, > which > is basically favoring speed over cryptographic strength. Exactly... we should default to a server with a preference for cryptographic strength, but I have no objection to offering a commented-out, clearly documented 'alternative' configuration favoring performance, provided that is clearly labeled as 'not for sensitive data'.
Re: Improving SSL config
On 06.10.2011 10:58, Rainer Jung wrote: > On 02.10.2011 09:07, William A. Rowe Jr. wrote: >> -1 in this respect; faster is not more secure. We must default to setting >> the strictest cipher choices, with a commented-out "this is faster, but far >> less secure" alternative for those with less targeted assets. >> >> If someone is enabling mod_ssl, it is to secure their traffic, not to speed >> up their server. >> >> And no, MD4, although immune to *this* vector, is simply not preferable. > > Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. > So there is a need to improve. My suggestion is a straight backport from > trunk. > > So what is the "strictest cipher choice" you suggest? Assuming s/MD4/RC4/ in Bill's message, it seems that SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 would be more appropriate for mod_ssl's default config. I agree that the current SSLCipherSuite default in 2.2.x should be improved (yes, right now it even includes suites with 40-bit encryption!), but giving specific precedence to RC4-SHA and AES128-SHA doesn't really feel right for a default config file. [1] Kaspar [1] in trunk, the SSLCipherSuite change in r966160 was inspired by http://journal.paul.querna.org/articles/2010/07/10/overclocking-mod_ssl/, which is basically favoring speed over cryptographic strength.
Re: Improving SSL config
On 06.10.2011 10:58, Rainer Jung wrote: > Hi Bill, > > On 02.10.2011 09:07, William A. Rowe Jr. wrote: >> On 9/29/2011 9:31 AM, Rainer Jung wrote: >>> In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) I suggest >>> we update our SSL configuration analogous to what's in trunk. >>> >>> - Choose a better default SSLCipherSuite >>> - Add SSLHonorCipherOrder >>> - restrict MSIE exceptions to MSIE 2-5 >> >> -1 in this respect; faster is not more secure. We must default to setting >> the strictest cipher choices, with a commented-out "this is faster, but far >> less secure" alternative for those with less targeted assets. >> >> If someone is enabling mod_ssl, it is to secure their traffic, not to speed >> up their server. >> >> And no, MD4, although immune to *this* vector, is simply not preferable. > > Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. > So there is a need to improve. My suggestion is a straight backport from > trunk. > > So what is the "strictest cipher choice" you suggest? I might have misunderstood you. Are you only worried about *activating* SSLHonorCipherOrder? Note that in trunk and as proposed here the corresponding comment and config block is commented, so not active by default. See my original post. Regards, Rainer
Re: Improving SSL config
Hi Bill, On 02.10.2011 09:07, William A. Rowe Jr. wrote: > On 9/29/2011 9:31 AM, Rainer Jung wrote: >> In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) I suggest >> we update our SSL configuration analogous to what's in trunk. >> >> - Choose a better default SSLCipherSuite >> - Add SSLHonorCipherOrder >> - restrict MSIE exceptions to MSIE 2-5 > > -1 in this respect; faster is not more secure. We must default to setting > the strictest cipher choices, with a commented-out "this is faster, but far > less secure" alternative for those with less targeted assets. > > If someone is enabling mod_ssl, it is to secure their traffic, not to speed > up their server. > > And no, MD4, although immune to *this* vector, is simply not preferable. Our current 2.2.x SSLCipherSuite contains e.g. SSLv2 and export ciphers. So there is a need to improve. My suggestion is a straight backport from trunk. So what is the "strictest cipher choice" you suggest? Regards, Rainer
Re: Improving SSL config
On 9/29/2011 9:31 AM, Rainer Jung wrote: > In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) I suggest > we update our SSL configuration analogous to what's in trunk. > > - Choose a better default SSLCipherSuite > - Add SSLHonorCipherOrder > - restrict MSIE exceptions to MSIE 2-5 -1 in this respect; faster is not more secure. We must default to setting the strictest cipher choices, with a commented-out "this is faster, but far less secure" alternative for those with less targeted assets. If someone is enabling mod_ssl, it is to secure their traffic, not to speed up their server. And no, MD4, although immune to *this* vector, is simply not preferable.
Re: Improving SSL config
On 29.09.2011 16:31, Rainer Jung wrote: > # SSL Cipher Suite: > # List the ciphers that the client is permitted to negotiate. > # See the mod_ssl documentation for a complete list. > -SSLCipherSuite > ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > +SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL Alternatively, it could be configured with a somewhat shorter SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5 (This produces the same list, but is more "whitelist based". We still have to ban aNULL and MD5, though.) > Furthermore I wonder whether we should activate the SSLHonorCipherOrder > in this config by default - at least for trunk. At the moment it is > commented out. That mostly depends on what SSLCipherSuite is set to, IMO. If RC4-SHA and AES128-SHA appear at the beginning, then turning on SSLHonorCipherOrder effectively means giving up perfect forward secrecy for many connections, as both of these cipher suites use RSA for key exchange. For Windows browsers which use Schannel for SSL/TLS - IE, most notably -, this doesn't make a real difference, that's true (Schannel has TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_RC4_128_SHA at the beginning of its default list). But OTOH browsers using Mozilla NSS, such as Firefox or Chrome, have suites with [EC]DHE key exchanges before those with RSA. In that latter case, turning SSLHonorCipher on makes these users lose PFS. > For 2.2.x it is possible people use OpenSSL older than 0.9.6 and the > directive will not work then. SSL_OP_CIPHER_SERVER_PREFERENCE was added to OpenSSL 0.9.7, to be precise. As ssl_cmd_SSLHonorCipherOrder() will hard fail in that case, turning it on has the risk of shipping a default config which fails to load. Kaspar
RE: Improving SSL config
> -Original Message- > From: Rainer Jung > Sent: Donnerstag, 29. September 2011 16:32 > To: dev@httpd.apache.org > Subject: Improving SSL config > > In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) > I suggest > we update our SSL configuration analogous to what's in trunk. > > - Choose a better default SSLCipherSuite > - Add SSLHonorCipherOrder > - restrict MSIE exceptions to MSIE 2-5 > > The patch looks like this: > > svn diff docs/conf/extra/httpd-ssl.conf.in > Index: docs/conf/extra/httpd-ssl.conf.in > === > --- docs/conf/extra/httpd-ssl.conf.in (revision 1177244) > +++ docs/conf/extra/httpd-ssl.conf.in (working copy) > @@ -87,8 +87,14 @@ > # SSL Cipher Suite: > # List the ciphers that the client is permitted to negotiate. > # See the mod_ssl documentation for a complete list. > -SSLCipherSuite > ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > +SSLCipherSuite > RC4-SHA:AES128-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL > > +# SSL Cipher Honor Order: > +# On a busy HTTPS server you may want to enable this directive > +# to force clients to use one of the faster ciphers like RC4-SHA > +# or AES128-SHA in the order defined by SSLCipherSuite. > +#SSLHonorCipherOrder on· > + > # Server Certificate: > # Point SSLCertificateFile at a PEM encoded certificate. If > # the certificate is encrypted, then you will be prompted for a > @@ -218,7 +224,7 @@ > # Similarly, one has to force some clients to use HTTP/1.0 > to workaround > # their broken HTTP/1.1 implementation. Use variables > "downgrade-1.0" and > # "force-response-1.0" for this. > -BrowserMatch ".*MSIE.*" \ > +BrowserMatch "MSIE [2-5]" \ > nokeepalive ssl-unclean-shutdown \ > downgrade-1.0 force-response-1.0 > > Furthermore I wonder whether we should activate the > SSLHonorCipherOrder > in this config by default - at least for trunk. At the moment it is > commented out. > > For 2.2.x it is possible people use OpenSSL older than 0.9.6 and the > directive will not work then. > > We might even backport the change to SSLCipherSuite and the MSIE > exceptions to 2.0. > > Any comments on: > > - Updating 2.2? +1 > - Activating SSLHonorCipher in trunk? -0: IMHO this is something the local admin should decide. > - Updating 2.0? -0.5: As users of 2.0 are unlikely to do new deployments they will use their existing configs and not use our examples. Furthermore doing stuff like this on 2.0 could set false expectations to users especially as we discussed on putting it EOL at a reasonable point in the future. Regards Rüdiger
Improving SSL config
In light of the TLS 1.0 CBC attack (aka BEAST, CVE-2011-3389) I suggest we update our SSL configuration analogous to what's in trunk. - Choose a better default SSLCipherSuite - Add SSLHonorCipherOrder - restrict MSIE exceptions to MSIE 2-5 The patch looks like this: svn diff docs/conf/extra/httpd-ssl.conf.in Index: docs/conf/extra/httpd-ssl.conf.in === --- docs/conf/extra/httpd-ssl.conf.in (revision 1177244) +++ docs/conf/extra/httpd-ssl.conf.in (working copy) @@ -87,8 +87,14 @@ # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. -SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL +SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL +# SSL Cipher Honor Order: +# On a busy HTTPS server you may want to enable this directive +# to force clients to use one of the faster ciphers like RC4-SHA +# or AES128-SHA in the order defined by SSLCipherSuite. +#SSLHonorCipherOrder on· + # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a @@ -218,7 +224,7 @@ # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. -BrowserMatch ".*MSIE.*" \ +BrowserMatch "MSIE [2-5]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 Furthermore I wonder whether we should activate the SSLHonorCipherOrder in this config by default - at least for trunk. At the moment it is commented out. For 2.2.x it is possible people use OpenSSL older than 0.9.6 and the directive will not work then. We might even backport the change to SSLCipherSuite and the MSIE exceptions to 2.0. Any comments on: - Updating 2.2? - Activating SSLHonorCipher in trunk? - Updating 2.0? Regards, Rainer
