Adam Shostack wrote:

> | No. The user would install the certificate on their computer, and they
> | would then not need a username and password at all (other than a
> | passphrase to protect the prvate key on their local machine - the
> | passphrase is never entered on a remote site, and the private key itself
> | is never sent of the machine anyway).
> |
> | Certificates are "the" solution to this problem.

> | No, assuming the real bank is verifying the client certificate for all
> | connections. It is impossible (without breaking SSL) to perform man in
> | the middle attacks when both client and server are using certificates.
>
> Really? It is impossible to perform a MITM if both sides are validating
> the certificates. If you visit phisher.screwthemall.com and that
> site has a server cert signed by a CA installed in the browser, then
> phisher can just visit your bank, get the challenge bits, send them on
> to you, and then send your responses to your bank. (I think. Its
> still somewhat early, but I can't see why SSL would break in a user
> visible way here.)
>

I'm not entirely sure if you are agreeing or disagreeing with me here.
Note that I said, if the connection is using mutually authenticated SSL
(i.e. both client and server present certificates to each other), there
is no way to MITM the connection, barring a cryptographic break of the
SSL protocol itself.

For a detailed explanation, please see
http://www.cgisecurity.com/owasp/html/ch07s04.html

The thing is, that if client certificates are used, nothing is ever
typed into a site that a phisher could use to impersonate you. So, no
phishing is possible.

>
> Shoot, a client implementation that, like SSH, remembered the banks
> cert, rather than throwing away that information in favor of a CA
> signature would improve things.
>
> Adam

And what would happen when the cert is renewed, as they are/should be on
an annual basis?

That is why the CA process was designed, to allow for this sort of thing.

Nonetheless, I hear what you are saying. If the cert of a site that we
have visited before changes, maybe a simple notification could be popped
up. But then I question the value of this. What do we want the user to
do? If this happens on a regular basis, with the various sites that they
visit, they will simply learn to click OK.

And if they visit a phisher, who is using a different site name, with a
different certificate, there will be nothing to compare with. This would
only identify the case where a phisher has managed to obtain a CA-signed
cert for the target server (www.mybank.com), managed to intercept your
connection to the real mybank.com, and route it to their own servers.

If they have done that, there are bigger problems!!!!

Regards,

Rogan
--
Rogan Dawes

*ALL* messages to discard (at) dawes.za (dot) net [email concealed] will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

[ reply ]

<br/>
<br/>
Adam Shostack wrote:<br/>
<br/>
> | No. The user would install the certificate on their computer, and they<br/>
> | would then not need a username and password at all (other than a<br/>
> | passphrase to protect the prvate key on their local machine - the<br/>
> | passphrase is never entered on a remote site, and the private key itself<br/>
> | is never sent of the machine anyway).<br/>
> | <br/>
> | Certificates are "the" solution to this problem.<br/>
<br/>
> | No, assuming the real bank is verifying the client certificate for all <br/>
> | connections. It is impossible (without breaking SSL) to perform man in <br/>
> | the middle attacks when both client and server are using certificates.<br/>
> <br/>
> Really? It is impossible to perform a MITM if both sides are validating<br/>
> the certificates. If you visit phisher.screwthemall.com and that<br/>
> site has a server cert signed by a CA installed in the browser, then<br/>
> phisher can just visit your bank, get the challenge bits, send them on<br/>
> to you, and then send your responses to your bank. (I think. Its<br/>
> still somewhat early, but I can't see why SSL would break in a user<br/>
> visible way here.)<br/>
><br/>
<br/>
I'm not entirely sure if you are agreeing or disagreeing with me here. <br/>
Note that I said, if the connection is using mutually authenticated SSL <br/>
(i.e. both client and server present certificates to each other), there <br/>
is no way to MITM the connection, barring a cryptographic break of the <br/>
SSL protocol itself.<br/>
<br/>
For a detailed explanation, please see <br/>
http://www.cgisecurity.com/owasp/html/ch07s04.html<br/>
<br/>
The thing is, that if client certificates are used, nothing is ever <br/>
typed into a site that a phisher could use to impersonate you. So, no <br/>
phishing is possible.<br/>
<br/>
> <br/>
> Shoot, a client implementation that, like SSH, remembered the banks<br/>
> cert, rather than throwing away that information in favor of a CA<br/>
> signature would improve things.<br/>
> <br/>
> Adam<br/>
<br/>
And what would happen when the cert is renewed, as they are/should be on <br/>
an annual basis?<br/>
<br/>
That is why the CA process was designed, to allow for this sort of thing.<br/>
<br/>
Nonetheless, I hear what you are saying. If the cert of a site that we <br/>
have visited before changes, maybe a simple notification could be popped <br/>
up. But then I question the value of this. What do we want the user to <br/>
do? If this happens on a regular basis, with the various sites that they <br/>
visit, they will simply learn to click OK.<br/>
<br/>
And if they visit a phisher, who is using a different site name, with a <br/>
different certificate, there will be nothing to compare with. This would <br/>
only identify the case where a phisher has managed to obtain a CA-signed <br/>
cert for the target server (www.mybank.com), managed to intercept your <br/>
connection to the real mybank.com, and route it to their own servers.<br/>
<br/>
If they have done that, there are bigger problems!!!!<br/>
<br/>
Regards,<br/>
<br/>
Rogan<br/>
-- <br/>
Rogan Dawes<br/>
<br/>
*ALL* messages to discard (at) dawes.za (dot) net [email concealed] will be dropped, and added<br/>
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

[ reply ]

<br/><br/>
<br/><br/>
Adam Shostack wrote:<br/><br/>
<br/><br/>
> | No. The user would install the certificate on their computer, and they<br/><br/>
> | would then not need a username and password at all (other than a<br/><br/>
> | passphrase to protect the prvate key on their local machine - the<br/><br/>
> | passphrase is never entered on a remote site, and the private key itself<br/><br/>
> | is never sent of the machine anyway).<br/><br/>
> | <br/><br/>
> | Certificates are "the" solution to this problem.<br/><br/>
<br/><br/>
> | No, assuming the real bank is verifying the client certificate for all <br/><br/>
> | connections. It is impossible (without breaking SSL) to perform man in <br/><br/>
> | the middle attacks when both client and server are using certificates.<br/><br/>
> <br/><br/>
> Really? It is impossible to perform a MITM if both sides are validating<br/><br/>
> the certificates. If you visit phisher.screwthemall.com and that<br/><br/>
> site has a server cert signed by a CA installed in the browser, then<br/><br/>
> phisher can just visit your bank, get the challenge bits, send them on<br/><br/>
> to you, and then send your responses to your bank. (I think. Its<br/><br/>
> still somewhat early, but I can't see why SSL would break in a user<br/><br/>
> visible way here.)<br/><br/>
><br/><br/>
<br/><br/>
I'm not entirely sure if you are agreeing or disagreeing with me here. <br/><br/>
Note that I said, if the connection is using mutually authenticated SSL <br/><br/>
(i.e. both client and server present certificates to each other), there <br/><br/>
is no way to MITM the connection, barring a cryptographic break of the <br/><br/>
SSL protocol itself.<br/><br/>
<br/><br/>
For a detailed explanation, please see <br/><br/>
http://www.cgisecurity.com/owasp/html/ch07s04.html<br/><br/>
<br/><br/>
The thing is, that if client certificates are used, nothing is ever <br/><br/>
typed into a site that a phisher could use to impersonate you. So, no <br/><br/>
phishing is possible.<br/><br/>
<br/><br/>
> <br/><br/>
> Shoot, a client implementation that, like SSH, remembered the banks<br/><br/>
> cert, rather than throwing away that information in favor of a CA<br/><br/>
> signature would improve things.<br/><br/>
> <br/><br/>
> Adam<br/><br/>
<br/><br/>
And what would happen when the cert is renewed, as they are/should be on <br/><br/>
an annual basis?<br/><br/>
<br/><br/>
That is why the CA process was designed, to allow for this sort of thing.<br/><br/>
<br/><br/>
Nonetheless, I hear what you are saying. If the cert of a site that we <br/><br/>
have visited before changes, maybe a simple notification could be popped <br/><br/>
up. But then I question the value of this. What do we want the user to <br/><br/>
do? If this happens on a regular basis, with the various sites that they <br/><br/>
visit, they will simply learn to click OK.<br/><br/>
<br/><br/>
And if they visit a phisher, who is using a different site name, with a <br/><br/>
different certificate, there will be nothing to compare with. This would <br/><br/>
only identify the case where a phisher has managed to obtain a CA-signed <br/><br/>
cert for the target server (www.mybank.com), managed to intercept your <br/><br/>
connection to the real mybank.com, and route it to their own servers.<br/><br/>
<br/><br/>
If they have done that, there are bigger problems!!!!<br/><br/>
<br/><br/>
Regards,<br/><br/>
<br/><br/>
Rogan<br/><br/>
-- <br/><br/>
Rogan Dawes<br/><br/>
<br/><br/>
*ALL* messages to discard (at) dawes.za (dot) net [email concealed] will be dropped, and added<br/><br/>
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

[ reply ]

<br/><br/><br/>
<br/><br/><br/>
Adam Shostack wrote:<br/><br/><br/>
<br/><br/><br/>
> | No. The user would install the certificate on their computer, and they<br/><br/><br/>
> | would then not need a username and password at all (other than a<br/><br/><br/>
> | passphrase to protect the prvate key on their local machine - the<br/><br/><br/>
> | passphrase is never entered on a remote site, and the private key itself<br/><br/><br/>
> | is never sent of the machine anyway).<br/><br/><br/>
> | <br/><br/><br/>
> | Certificates are "the" solution to this problem.<br/><br/><br/>
<br/><br/><br/>
> | No, assuming the real bank is verifying the client certificate for all <br/><br/><br/>
> | connections. It is impossible (without breaking SSL) to perform man in <br/><br/><br/>
> | the middle attacks when both client and server are using certificates.<br/><br/><br/>
> <br/><br/><br/>
> Really? It is impossible to perform a MITM if both sides are validating<br/><br/><br/>
> the certificates. If you visit phisher.screwthemall.com and that<br/><br/><br/>
> site has a server cert signed by a CA installed in the browser, then<br/><br/><br/>
> phisher can just visit your bank, get the challenge bits, send them on<br/><br/><br/>
> to you, and then send your responses to your bank. (I think. Its<br/><br/><br/>
> still somewhat early, but I can't see why SSL would break in a user<br/><br/><br/>
> visible way here.)<br/><br/><br/>
><br/><br/><br/>
<br/><br/><br/>
I'm not entirely sure if you are agreeing or disagreeing with me here. <br/><br/><br/>
Note that I said, if the connection is using mutually authenticated SSL <br/><br/><br/>
(i.e. both client and server present certificates to each other), there <br/><br/><br/>
is no way to MITM the connection, barring a cryptographic break of the <br/><br/><br/>
SSL protocol itself.<br/><br/><br/>
<br/><br/><br/>
For a detailed explanation, please see <br/><br/><br/>
http://www.cgisecurity.com/owasp/html/ch07s04.html<br/><br/>
<br/>
<br/><br/><br/>
The thing is, that if client certificates are used, nothing is ever <br/><br/><br/>
typed into a site that a phisher could use to impersonate you. So, no <br/><br/><br/>
phishing is possible.<br/><br/><br/>
<br/><br/><br/>
> <br/><br/><br/>
> Shoot, a client implementation that, like SSH, remembered the banks<br/><br/><br/>
> cert, rather than throwing away that information in favor of a CA<br/><br/><br/>
> signature would improve things.<br/><br/><br/>
> <br/><br/><br/>
> Adam<br/><br/><br/>
<br/><br/><br/>
And what would happen when the cert is renewed, as they are/should be on <br/><br/><br/>
an annual basis?<br/><br/><br/>
<br/><br/><br/>
That is why the CA process was designed, to allow for this sort of thing.<br/><br/><br/>
<br/><br/><br/>
Nonetheless, I hear what you are saying. If the cert of a site that we <br/><br/><br/>
have visited before changes, maybe a simple notification could be popped <br/><br/><br/>
up. But then I question the value of this. What do we want the user to <br/><br/><br/>
do? If this happens on a regular basis, with the various sites that they <br/><br/><br/>
visit, they will simply learn to click OK.<br/><br/><br/>
<br/><br/><br/>
And if they visit a phisher, who is using a different site name, with a <br/><br/><br/>
different certificate, there will be nothing to compare with. This would <br/><br/><br/>
only identify the case where a phisher has managed to obtain a CA-signed <br/><br/><br/>
cert for the target server (www.mybank.com), managed to intercept your <br/><br/><br/>
connection to the real mybank.com, and route it to their own servers.<br/><br/><br/>
<br/><br/><br/>
If they have done that, there are bigger problems!!!!<br/><br/><br/>
<br/><br/><br/>
Regards,<br/><br/><br/>
<br/><br/><br/>
Rogan<br/><br/><br/>
-- <br/><br/><br/>
Rogan Dawes<br/><br/><br/>
<br/><br/><br/>
*ALL* messages to discard (at) dawes.za (dot) net [email concealed] will be dropped, and added<br/><br/><br/>
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

[ reply ]