Topic: https for mtgox (Read 1051 times)
Could anyone here provide a screenshot ?
Quote from: Paweł Krawczyk link=http://blog.ivanristic.com/2009/08/is-rc4-safe-for-use-in-ssl.htm
[...] TLS_RSA_WITH_RC4_128_MD5 [...] is extremely widespread among commercial servers. Main reasons are 1) it's default preferred cipher in most versions of IIS, 2) these two algorithms are absolutely fastest and least CPU-intensive.
However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.
This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.
On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.
And...
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.
However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.
This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.
On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.
And...
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.
Summary:
RC4_128 WIFI (WEP) = Not secure
RC4_128 HTTPS = Secure w/ no known exploits
AES/RC6 HTTPS = Most secure & recommended
amirite?
The vast majority of WiFi points with WAP are actually using RC4 and dont know it. WPA TKIP, temporal key interchange protocol, aka exchange keys faster so that RC4 is secure.
google chrome shows me this*
*note: this isn't my screenshot, the picture is just illustrating how chrome puts a line through https:/ to symbolize insecurity
When you click on it, it tells you what is insecure about it.
*note: this isn't my screenshot, the picture is just illustrating how chrome puts a line through https:/ to symbolize insecurity
When you click on it, it tells you what is insecure about it.
Quote from: Paweł Krawczyk link=http://blog.ivanristic.com/2009/08/is-rc4-safe-for-use-in-ssl.htm
[...] TLS_RSA_WITH_RC4_128_MD5 [...] is extremely widespread among commercial servers. Main reasons are 1) it's default preferred cipher in most versions of IIS, 2) these two algorithms are absolutely fastest and least CPU-intensive.
However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.
This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.
On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.
And...
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.
However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.
This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.
On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.
And...
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.
Summary:
RC4_128 WIFI (WEP) = Not secure
RC4_128 HTTPS = Secure w/ no known exploits
AES/RC6 HTTPS = Most secure & recommended
amirite?
Brand new 
It says it's not secure because its using RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism.
Probably still a work in progress, amirite?
It says it's not secure because its using RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism.
Probably still a work in progress, amirite?
What says that isn't secure?
Brand new
It says it's not secure because its using RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism.
Probably still a work in progress, amirite?
It says it's not secure because its using RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism.
Probably still a work in progress, amirite?
Jump to: