RE: BREACH vuln and ciphers
Ø This attack is compression at the application layer not ssl compression. TLS fails to protect the application layer data. SSL also fails to protect application layer data when the application decides to include key material. There are limits to what can be done. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: BREACH vuln and ciphers
This attack is compression at the application layer not ssl compression. TLS fails to protect the application layer data. On Aug 6, 2013 10:18 AM, "Viktor Dukhovni" wrote: > On Tue, Aug 06, 2013 at 09:20:06AM -0500, Rodney Beede wrote: > > > Why can't we get a simplified version of TLS that has only one option of > > the most secure cipher and isn't vulnerable to things like BEAST, CRIME, > or > > BREACH? > > These are not TLS problems, these are a special case of cross-site > HTML/HTTP problems, that TLS fails to exclude. Most application > protocols are not subject to the chosen plaintext injection attacks > facilitated by browsers. > > > Could we define a TLS version 2.0 with one cipher that was not vulnerable > > and one simple config? All clients would simply be vulnerable until they > > upgraded or patched to support TLS 2.0. For web servers that don't > support > > the fixed and simplified version have the browser show a warning that the > > site is not secure regardless whether or not the ssl cert is valid. > > TLS can't prevent all problems with HTTP. Avoiding compression > helps. Browsers should disable compression at the TLS layer, and > let the application layer handle compression when applicable. > > When I compiled OpenSSL for previous employer, I always disabled > compression, even before the various compression attacks were made > public. I always thought that compression belonged elsewhere in the > protocol stack, and the SSL layer never had enough information about > whether to optimize for bandwidth or CPU cost. > > -- > Viktor. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Using both PSK and "classic" RSA
>From my initial reading of the spec (RFC 4279) and review of the code, it >appears that both PSK and RSA-style key exchanges can exist in both server and >client. That is: - A server can register the PSK callbacks, identities, and keypair and talk to clients using the PSK and RSA key exchange. - A client can talk register the PSK callbacks and identities, and will be able to connect to both PSK and RSA servers And of course a client or server that registers only one set can only talk to a server or client with the right algorithm. Anyone doing this? Anyone aware of any special gotcha's or concerns? Tnx. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: Using PKCS#1 instead of PKCS#8
Well my first thought is PKCS12. And I found this link for PKCS12 maybe this might help. http://danielpocock.com/strongswan-debian-rhel-fedora-with-android-client -- View this message in context: http://openssl.6102.n7.nabble.com/Using-PKCS-1-instead-of-PKCS-8-tp46071p46072.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Using PKCS#1 instead of PKCS#8
Good morning, all! I'm trying to get openssh to generate some self-signed certificates for a test VPN using Strongswan IPsec 4.5.2. This version will not read private keys in the PKCS#8 format. Is there a way to either convert PKCS#8 keys to the older version, or, alternately, specify the older version when generating keys? Thanks to all in advance for looking into this! Gregg Gregg Hughes IT Administrator www.iscinternational.com 414.721.0301 phone 262.313.3106 fax
Re: BREACH vuln and ciphers
On Tue, Aug 06, 2013 at 09:20:06AM -0500, Rodney Beede wrote: > Why can't we get a simplified version of TLS that has only one option of > the most secure cipher and isn't vulnerable to things like BEAST, CRIME, or > BREACH? These are not TLS problems, these are a special case of cross-site HTML/HTTP problems, that TLS fails to exclude. Most application protocols are not subject to the chosen plaintext injection attacks facilitated by browsers. > Could we define a TLS version 2.0 with one cipher that was not vulnerable > and one simple config? All clients would simply be vulnerable until they > upgraded or patched to support TLS 2.0. For web servers that don't support > the fixed and simplified version have the browser show a warning that the > site is not secure regardless whether or not the ssl cert is valid. TLS can't prevent all problems with HTTP. Avoiding compression helps. Browsers should disable compression at the TLS layer, and let the application layer handle compression when applicable. When I compiled OpenSSL for previous employer, I always disabled compression, even before the various compression attacks were made public. I always thought that compression belonged elsewhere in the protocol stack, and the SSL layer never had enough information about whether to optimize for bandwidth or CPU cost. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
BREACH vuln and ciphers
Why can't we get a simplified version of TLS that has only one option of the most secure cipher and isn't vulnerable to things like BEAST, CRIME, or BREACH? http://www.kb.cert.org/vuls/id/987798 What is it about the ciphers that they cannot protect the data whether compressed or not? Would using AES for at rest data be vulnerable if it was compressed first? Even with the same style attack I would guess not. Could we define a TLS version 2.0 with one cipher that was not vulnerable and one simple config? All clients would simply be vulnerable until they upgraded or patched to support TLS 2.0. For web servers that don't support the fixed and simplified version have the browser show a warning that the site is not secure regardless whether or not the ssl cert is valid. Because of the mess of supporting older clients and complex configs the value of SSL/TLS is greatly diminished.
Re: Using CA signing for a cert and Organization Name setting
Thank you Stefan That worked perfect changing the policy optional to supplied in the # For the CA policy [ policy_match ] organizationName= supplied -- View this message in context: http://openssl.6102.n7.nabble.com/Using-CA-signing-for-a-cert-and-Organization-Name-setting-tp46056p46064.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
