 |
|
| Science Forum Index » Cryptography Forum » SSL MIM attack... |
|
Page 1 of 1 |
|
| Author |
Message |
| Pierre Fichaud... |
 Posted: Fri Oct 30, 2009 9:49 am |
|
|
|
Guest
|
Hello All,
I am new here.
I am developing the server side SSL interface in C on an IBM mainframe.
I have been reading the RFC 5246 which describes SSL. How does SSL
prevent an MIM attack wherein a client becomes the MIM? The rogue client
can provide its own certificate that will validate correctly on the server.
Thanks, Pierre. |
|
|
| Back to top |
|
|
|
| robertwessel2 at (no spam) yahoo.com... |
| Posted: Fri Oct 30, 2009 12:09 pm |
|
|
|
Guest
|
On Oct 30, 10:49 am, Pierre Fichaud <pr... at (no spam) videotron.com> wrote:
[quote]Hello All,
I am new here.
I am developing the server side SSL interface in C on an IBM mainframe.
I have been reading the RFC 5246 which describes SSL. How does SSL
prevent an MIM attack wherein a client becomes the MIM? The rogue client
can provide its own certificate that will validate correctly on the server.
[/quote]
How would the rogue client authenticate itself to the real client?
Without the server's cert, it cannot, so the real client would fail
the session. |
|
|
| Back to top |
|
|
|
| mike clark... |
| Posted: Mon Nov 02, 2009 4:34 am |
|
|
|
Guest
|
On Nov 2, 6:47 am, Pierre Fichaud <pr... at (no spam) videotron.com> wrote:
[quote]Robert,
The rogue client, as the man in the middle, will intercept the server's
certificate. It would validate the server's certificate and send its own
certificate to the server, if requested by the server. It would also
send a fake server certificate to the real client. It would also have
the private key of this fake certificate so it could communicate with
the real client.
In being the man in the middle, the rogue client assumes the identity
of the real client as fas as the server is concerned and assumes the
identity of the server as far as the real client is concerned.
Pierre.
[/quote]
Why would the real server trust the fake server's certificate? Why
would the real client trust the fake server's certificate?
Mike |
|
|
| Back to top |
|
|
|
| mike clark... |
| Posted: Mon Nov 02, 2009 6:10 am |
|
|
|
Guest
|
On Nov 2, 8:02 am, Pierre Fichaud <pr... at (no spam) videotron.com> wrote:
[quote]mike clark wrote:
On Nov 2, 6:47 am, Pierre Fichaud <pr... at (no spam) videotron.com> wrote:
Robert,
The rogue client, as the man in the middle, will intercept the server's
certificate. It would validate the server's certificate and send its own
certificate to the server, if requested by the server. It would also
send a fake server certificate to the real client. It would also have
the private key of this fake certificate so it could communicate with
the real client.
In being the man in the middle, the rogue client assumes the identity
of the real client as fas as the server is concerned and assumes the
identity of the server as far as the real client is concerned.
Pierre.
Why would the real server trust the fake server's certificate? Why
would the real client trust the fake server's certificate?
Mike
Because the fake client's certificate has been signed by a CA. There is
nothing preventing the bad guy from getting a certificate signed by a
CA. Certificate's only prove that the sender is indeed what's been coded
in the subject and issuer fields.
We are talking about a product that has clients running on different
machines. The server is running on an IBM mainframe. The product is
produced in-house by a software company and so has complete control of
the packaging of the product. The customer installs the server part of
the product on the mainframe and the client parts on non-mainframe
platforms. The customer has complete control of the installation.
Pierre.
[/quote]
Well, obviously you can validate certificates how ever you want.
Simply because the cert is signed by the CA, however, doesn't mean it
should be validated. Take browsers for example. If I go to https://mail.google.com
and the MITM responds to me with a certificate for https://mail.googlehacker.com,
then should I accept that certificate as being valid? Remember that
certificates have a common name (CN). No trustworthy CA would sign any
old certificate with the CN set to mail.google.com. Therefore, by
making sure the cert is signed by the CA and by checking fields like
the CN in the certificate, this attack is useless.
It is the same for client certificates. If the client claims to be
Alice, but the certificate says the client's name is Trudy, then
obviously the authentication should fail. Does that make sense? |
|
|
| Back to top |
|
|
|
| Pierre Fichaud... |
| Posted: Mon Nov 02, 2009 8:47 am |
|
|
|
Guest
|
Robert,
The rogue client, as the man in the middle, will intercept the server's
certificate. It would validate the server's certificate and send its own
certificate to the server, if requested by the server. It would also
send a fake server certificate to the real client. It would also have
the private key of this fake certificate so it could communicate with
the real client.
In being the man in the middle, the rogue client assumes the identity
of the real client as fas as the server is concerned and assumes the
identity of the server as far as the real client is concerned.
Pierre.
robertwessel2 at (no spam) yahoo.com wrote:
[quote]On Oct 30, 10:49 am, Pierre Fichaud <pr... at (no spam) videotron.com> wrote:
Hello All,
I am new here.
I am developing the server side SSL interface in C on an IBM mainframe.
I have been reading the RFC 5246 which describes SSL. How does SSL
prevent an MIM attack wherein a client becomes the MIM? The rogue client
can provide its own certificate that will validate correctly on the server.
How would the rogue client authenticate itself to the real client?
Without the server's cert, it cannot, so the real client would fail
the session.[/quote] |
|
|
| Back to top |
|
|
|
| Carsten Krueger... |
| Posted: Mon Nov 02, 2009 8:55 am |
|
|
|
Guest
|
Am Mon, 02 Nov 2009 08:47:24 -0500 schrieb Pierre Fichaud:
[quote]Robert,
The rogue client, as the man in the middle, will intercept the server's
certificate. It would validate the server's certificate and send its own
certificate to the server, if requested by the server. It would also
send a fake server certificate to the real client. It would also have
the private key of this fake certificate so it could communicate with
the real client.
In being the man in the middle, the rogue client assumes the identity
of the real client as fas as the server is concerned and assumes the
identity of the server as far as the real client is concerned.
[/quote]
Please do not implement SSL.
Read a book, e.g. SSL for dummies
greetings
Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/ |
|
|
| Back to top |
|
|
|
| Pierre Fichaud... |
| Posted: Mon Nov 02, 2009 10:02 am |
|
|
|
Guest
|
mike clark wrote:
[quote]On Nov 2, 6:47 am, Pierre Fichaud <pr... at (no spam) videotron.com> wrote:
Robert,
The rogue client, as the man in the middle, will intercept the server's
certificate. It would validate the server's certificate and send its own
certificate to the server, if requested by the server. It would also
send a fake server certificate to the real client. It would also have
the private key of this fake certificate so it could communicate with
the real client.
In being the man in the middle, the rogue client assumes the identity
of the real client as fas as the server is concerned and assumes the
identity of the server as far as the real client is concerned.
Pierre.
Why would the real server trust the fake server's certificate? Why
would the real client trust the fake server's certificate?
Mike
Because the fake client's certificate has been signed by a CA. There is[/quote]
nothing preventing the bad guy from getting a certificate signed by a
CA. Certificate's only prove that the sender is indeed what's been coded
in the subject and issuer fields.
We are talking about a product that has clients running on different
machines. The server is running on an IBM mainframe. The product is
produced in-house by a software company and so has complete control of
the packaging of the product. The customer installs the server part of
the product on the mainframe and the client parts on non-mainframe
platforms. The customer has complete control of the installation.
Pierre. |
|
|
| Back to top |
|
|
|
| Gordon Burditt... |
| Posted: Mon Nov 02, 2009 10:38 pm |
|
|
|
Guest
|
[quote] The rogue client, as the man in the middle, will intercept the
server's
certificate. It would validate the server's certificate and send its own
certificate to the server, if requested by the server. It would also
send a fake server certificate to the real client. It would also have
the private key of this fake certificate so it could communicate with
the real client.
In being the man in the middle, the rogue client assumes the identity
of the real client as fas as the server is concerned and assumes the
identity of the server as far as the real client is concerned.
Pierre.
Why would the real server trust the fake server's certificate?
[/quote]
In many applications (e-commerce, for instance), client certificates
aren't even asked for. Clients usually don't have to authenticate
themselves *before* creating an account, and access to a particular
account is often done by username/password. The main authentication
is often the validity of the credit card as determined by the payment
processor.
In applications where client certificates *are* asked for, the
server will usually insist that the client certificate be signed
by a *particular* CA, whose certificate is configured in the software,
(as distinguished from "presented by the client") possibly a CA run
by the same organization that runs the server. It may also tie the
username on the certificate to an account on the system.
[quote]Why
would the real client trust the fake server's certificate?
[/quote]
The real client would trust the fake server's certificate if that
certificate is signed by a CA on the client's list of authorized
CAs (lots of these are pre-loaded into web browsers). Otherwise,
it would complain. Thus, a social-engineering attack on Verisign
or a similar CA is possible, using fake documents to appear to be
the real company involved. Also, if you can fake out the client
into loading a certificate for a rogue CA, and marking it trusted,
you can suppress the warning. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Wed Dec 02, 2009 11:02 am
|
|