its called copyleft for a reason. It represents a typical left-wing approach to control thought and expression. Resist GPL -- support Berkeley, Apache, and the many other more libertarian licenses.
GNU: Free as in Freedom?
Nah, not unless you believe in Democratic as in Democratic People's Republic of Korea.
The broswer checks that the hostname in the CN field of the certificate matches the hostname it thinks it is connecting to. This blocks the mitm attack.
What exactly is your your man-in-the-middle attack? What exactly will your man in the middle do that will subvert my connection to https://www.verisign.com/? I don't think there is the mitm attack you are claiming, but I can't be sure what you are claiming.
--greg
I consider myself somewhat knowledgable about cryptography in general and SSL in particular. I read the articles by Kurt Seifried, especially the "foundation" articles dates Sep 30, 1999 and Oct 7, 1999. He is very cagey about actually demonstrating an attack, but I think his points are either technically wrong or technically useless.
First, the technically useless. Every security product/protocol I am aware of is vulnerable to so-called social engineering attacks. That's their whole point! They go around the security perimeter and get "behind" the protection to get humans to give away information. It is certianly fair to analyze the ease to which some products/protocols facilitate this, but I didn't see much of that. Instead, the articles discuss a company called DigitalBond with a solution that perhaps is also vulnerable to social engineering attacks.
Now lets look at the technical attacks and claims, which are contained in the Sep 30th article. I'll only comment on the weaknesses he alleges are in SSL. His first claim is that you should not order from a store that uses the http GET method. He doesn't say why, and I cannot think of any reason. If the form is submitted with an SSL-secured action (action="https:...") then both are equally secure.
His next claim is that the user must inspect the certificate of the server every for every SSL connection. He does not say what attack he can mount if the user doesn't do this. I am guessing that he believes the man-in-the-middle can substitute his own certificates and appear to be legitimate. This is firstly not an attack on the SSL protocol, only perhaps on implementations, and secondly it does not work with the implentations I have tested, IE 5+ and Netscape 4.7+. These implementations verify that the hostname you asked the browser to connect to matches the hostname specified in the CN field of the certificate. Of course, you must trust that the CA will do some checking to make sure hostnames actualy belong to the entity getting the certificate, but that is way outside the scope of the SSL protocol. These "flaws" cannot be the basis for later claims of insecurities.
These implementations do not rely entirely on having savvy users carefully inspect every certificate.
I'd like to check up on earlier broswer versions to see if they also behave similarly. I'd be particularly interested in browsers that were in play at the time the article was written, say fall of 1999.
--greg
Slashdot Mirror
By "personal freedom", he means "having sex with children".
its called copyleft for a reason. It represents a typical left-wing approach to control thought and expression. Resist GPL -- support Berkeley, Apache, and the many other more libertarian licenses.
GNU: Free as in Freedom?
Nah, not unless you believe in Democratic as in Democratic People's Republic of Korea.
The broswer checks that the hostname in the CN field of the certificate matches the hostname it thinks it is connecting to. This blocks the mitm attack.
What exactly is your your man-in-the-middle attack? What exactly will your man in the middle do that will subvert my connection to https://www.verisign.com/? I don't think there is the mitm attack you are claiming, but I can't be sure what you are claiming. --greg
I consider myself somewhat knowledgable about cryptography in general and SSL in particular. I read the articles by Kurt Seifried, especially the "foundation" articles dates Sep 30, 1999 and Oct 7, 1999. He is very cagey about actually demonstrating an attack, but I think his points are either technically wrong or technically useless.
First, the technically useless. Every security product/protocol I am aware of is vulnerable to so-called social engineering attacks. That's their whole point! They go around the security perimeter and get "behind" the protection to get humans to give away information. It is certianly fair to analyze the ease to which some products/protocols facilitate this, but I didn't see much of that. Instead, the articles discuss a company called DigitalBond with a solution that perhaps is also vulnerable to social engineering attacks.
Now lets look at the technical attacks and claims, which are contained in the Sep 30th article. I'll only comment on the weaknesses he alleges are in SSL. His first claim is that you should not order from a store that uses the http GET method. He doesn't say why, and I cannot think of any reason. If the form is submitted with an SSL-secured action (action="https:...") then both are equally secure.
His next claim is that the user must inspect the certificate of the server every for every SSL connection. He does not say what attack he can mount if the user doesn't do this. I am guessing that he believes the man-in-the-middle can substitute his own certificates and appear to be legitimate. This is firstly not an attack on the SSL protocol, only perhaps on implementations, and secondly it does not work with the implentations I have tested, IE 5+ and Netscape 4.7+. These implementations verify that the hostname you asked the browser to connect to matches the hostname specified in the CN field of the certificate. Of course, you must trust that the CA will do some checking to make sure hostnames actualy belong to the entity getting the certificate, but that is way outside the scope of the SSL protocol. These "flaws" cannot be the basis for later claims of insecurities. These implementations do not rely entirely on having savvy users carefully inspect every certificate.
I'd like to check up on earlier broswer versions to see if they also behave similarly. I'd be particularly interested in browsers that were in play at the time the article was written, say fall of 1999.
--greg