From: Bill Browning <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: RE: How can I encrypt public key in handshake?
Date sent: Tue, 20 Mar 2001 15:29:05 -0800
Send reply to: [EMAIL PROTECTED]
I don't understand why he does not just select the SRP package and
be done with it. It has strong encryption, and protects againt the
MITM attacks, etc. Then if a decision is made later on to use
SSL/TLS, its alreay there. Just install the server/client certs and it's
done.
Ken
okay, well try this approach:
1. Give your public key to anyone who want its (email what ever..)
2. create an SSL connection from client to server.
3. Verify that the server is who you think it is (via the public key)
(client can now trust server)
4. Pass an encrypted token to the client (encrypted with client password)
5. client decrypts and replies with the decrypted token ( server can now
trust client )
This should accomplish what you are talking about with out changing SSL and
avoiding MIM attacks. Once step 3 has been completed the client knows the
server has the proper private key, and you have a secure connection. The
connection has been negotiated using the servers private key (cipher key for
the connection is encrypted with the servers public key, server decrypts it
with it's private key). So after step 3 you are sure that you are talking to
whomever posses the private key - avoided MIM attack, correct? Now if you
use Ephemeral RSA or Diffie-Hellman you loose the ability to authenticate
the server, at which point you are susceptible to MIM because you don't
really know who is at the other end. As long as you can authenticate the
certificate sent by the server from some CA (could be as simple as already
having the certificate in your clients personal CA) I am a bit at a loss as
to how someone would implement a MIM attack. Now you've really got me
curious as to what I missed in this. I can't claim in any way to be an
expert on the subject (having never contributed anything significant to the
openSSL movement) so please let me know if there is a hole in my thinking
here, I'm always trying to learn more about SSL and crypto in general.
On an alternate question how do you plan to avoid a brute force attack? I
could just capture the public key that you've encrypted with the clients
password and brute force the public key from it. Then I could perform the
scheme I proposed in my previous message without ever being a real client. I
would have the public key and could pretend to be any client I wished. Since
you always depend on sending the same encrypted packet over the wire you've
weakened your security, no? The nice thing about SSL is that the key is
chosen at (pseudo)random every time you make a new connection. So if you
crack one session you've only cracked that session, not any session that
comes afterwards.
Cheers!
Bill Browning
-----Original Message-----
From: corky peavy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 2:56 PM
To: [EMAIL PROTECTED]
Subject: RE: How can I encrypt public key in handshake?
Thanks for your reply helping me think this through.
> It sound like what you are doing should happen like this:
>
> 1. Client (C) connects to Server (s)
> 2. S gets user name from C
> 3. S encrypts public key using password for C
> 4. S sends password to C
> 5. C saves password for use with SSL_CTX_load_verify_locations
> 6. C starts an ssl negotiation with S.
>
Are you saying this type of approach could work for me, or are you thinking
this is what I want to do?
To meet my need, the public key should not be sent in the clear. I need
all of SSL's normal robustness in tamper detection right from the start,
but without exposing the key. The SSL negotiation is required to send
the public key isn't it?
In various articles I have read, they point out that many people are
using SSL w/o certificates, or only on the server side, and that it is
pretty weak in that case because it is vulnerable to man-in-the-middle
attacks, and that is my situation too - I need to use it without
certificates.
> What you are trying to do is basically a *huge* violation of SSL.
Well, it beats what many people are doing - just using it without
certificates.
I am beginning to see after 3 days of poking at it, that it is *hugely*
hard for someone unfamiliar with the code to figure out where to do the
encrypt/decrypt!!! :-\
> Changing it to do so will render it unusable with other applications.
That would be a benefit for my application.
> Why do you need to encrypt the public key? Can you not encrypt some
other token with their
> password and ask for a response token of some sort?
Doing that prevents me from detecting that someone stepped in the middle.
If I use SSL as usual, except with and encrypted public key, they can't
step in the middle any more, because they can't form packets the server
will decrypt since they don't have the public key.
> Public keys are designed to be just that, public.
Yes, SSL depends on certificates to deal with man in the middle problems
which public keys expose me to.
Unfortunately, my customers won't be able to bear the burden of dealing
with certificates. My systems will be used with a very small number
of trusted and experienced users. Passwords work pretty well in that
case - but I can't let the public key go out, or I am an easy target.
> From what you have described you have not
> avoided a man in the middle attack. All I have to do is as follows:
>
> 1. I am C' (a second client)
> 2. I connect in a legitimate fashion and you send me the Public key
> encrypted with my password.
#2 can only be accomplished if you have a valid username/password. If
you have that, you can do grave damage to me already. Anyway, as I
say, that is not something I am trying to defend against, because our
situation is such that the risk there is very low.
I could imagine someone MIGHT be able to pose as a server, but that poses
no threat for my application. Clients don't send anything useful to servers.
Hopefully I have persuaded you that I am trying to do something reasonable.
If so, I am even more hoping you will give me the keys to the kingdom,
in the form of some tips about how to encrypt decrypt the pub keys.
Pretty please? :-)
-Corky
__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__________________________________________________
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-560-9170
[EMAIL PROTECTED]
http://www.securenetterm.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
