Bitcoin Forum
December 04, 2016, 12:37:42 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: https for mtgox  (Read 828 times)
GeniuSxBoY
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 11, 2011, 03:44:40 PM
 #1

Brand new Smiley


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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480855062
Hero Member
*
Offline Offline

Posts: 1480855062

View Profile Personal Message (Offline)

Ignore
1480855062
Reply with quote  #2

1480855062
Report to moderator
phantomcircuit
Sr. Member
****
Offline Offline

Activity: 463


View Profile
July 11, 2011, 03:57:33 PM
 #2

Brand new Smiley


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?
RchGrav
Full Member
***
Offline Offline

Activity: 149



View Profile
July 11, 2011, 04:42:41 PM
 #3

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.

Summary:

RC4_128 WIFI (WEP) = Not secure
RC4_128 HTTPS        = Secure w/ no known exploits
AES/RC6 HTTPS        = Most secure & recommended

amirite?

4C 6F 6E 67  4C 69 76 65  42 69 74 63 6F 69 6E
Qba'g lbh unir nalguvat orggre gb qb?
GeniuSxBoY
Hero Member
*****
Offline Offline

Activity: 546



View Profile
July 11, 2011, 05:28:25 PM
 #4

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.
phantomcircuit
Sr. Member
****
Offline Offline

Activity: 463


View Profile
July 12, 2011, 05:26:28 AM
 #5

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.

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.
MagicalTux
VIP
Hero Member
*
Offline Offline

Activity: 617


Working on new MtGox features


View Profile WWW
July 12, 2011, 11:28:44 PM
 #6

Could anyone here provide a screenshot ?

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!