Michael Ekstrand enlightened us with:
clients aren't expected to have their own certificates. I think that
the only time you really need the clients to have certificates is
when the certificate *is* your authentication (e.g., in OpenVPN).
Fact remains that a strong certificate is much more
Sybren Stuvel wrote:
Michael Ekstrand enlightened us with:
clients aren't expected to have their own certificates. I think that
the only time you really need the clients to have certificates is
when the certificate *is* your authentication (e.g., in OpenVPN).
Fact remains that a strong
Frank Millman [EMAIL PROTECTED] writes:
You also want to generate a client
certificate to install on the server.
Both you and Sybren are insistent that this is a necessary step, but I
confess I cannot see the need for it. The client is lightweight, and
authenticates itself to the server
Paul Rubin enlightened us with:
The client cert approach isn't strictly necessary but it means that
the SSL stack takes care of stuff that your application would
otherwise have to take care of at both the client and the server
side.
Indeed. I always try to take the route of the least wheels I
Sybren Stuvel wrote:
Frank Millman enlightened us with:
If I understand correctly, a 'man-in-the-middle' attack would
involve someone setting up a 'pseudo server', which gives the
correct responses to the client's attempt to log in
That's right. Usually it's done by proxying the data
Frank Millman [EMAIL PROTECTED] writes:
I don't know how to check the certificates. None of the documentation I
have read spells out in detail how to do this.
Lemme see if I can find you something--I'll put up another post if I do.
What about this idea? I am not looking for a state-of-the-art
Paul Rubin enlightened us with:
If you're paranoid, you can scrounge some $20 obsolete laptop from
ebay and dedicate it to use as a CA, never letting it touch the
internet (transfer files to and from it on floppy disc).
caCert use a special box for this too. It has no network connection,
and
Frank Millman enlightened us with:
I don't know how to check the certificates. None of the
documentation I have read spells out in detail how to do this.
Read the readme that comes with TLS Lite. You can require certificate
checks, call certchain.validate(CAlist), and with my extension you can
Paul Rubin wrote:
Frank Millman [EMAIL PROTECTED] writes:
I don't know how to check the certificates. None of the documentation I
have read spells out in detail how to do this.
Lemme see if I can find you something--I'll put up another post if I do.
Thanks
Didn't you say wireless?
Disclaimer: I am not an expert. Take this with a grain of salt... but
I'll throw it out for what it's worth.
On 14 Mar 2006 04:12:38 -0800
Frank Millman [EMAIL PROTECTED] wrote:
Using openssl, generate a key for the server, generate a
self-signed certificate, and extract the sha1
Michael Ekstrand wrote:
Disclaimer: I am not an expert. Take this with a grain of salt... but
I'll throw it out for what it's worth.
For what it's worth, the Web does not authenticate clients (for the
most part anyway). The server is authenticated - its certificate is
checked against the
Hi all
I am writing a multi-user accounting/business application, which uses
sockets to communicate between client and server. I want to offer the
option of encrypting the traffic between the two. The main reason for
this is to cater for wireless communication.
I have read up on SSL, and more or
Frank Millman enlightened us with:
while 1:
conn,addr = s.accept()
c = TLSConnection(conn)
c.handshakeServer(certChain=certChain,privateKey=privateKey)
data = c.recv(1024)
It's nice that you set up a TLS connection, but you never check the
certificate of the other
Sybren Stuvel wrote:
Frank Millman enlightened us with:
while 1:
conn,addr = s.accept()
c = TLSConnection(conn)
c.handshakeServer(certChain=certChain,privateKey=privateKey)
data = c.recv(1024)
It's nice that you set up a TLS connection, but you never check
Frank Millman [EMAIL PROTECTED] writes:
I was hoping to avoid this step. The point of the exercise for me is
encryption. I am not too worried about authentication. The next step in
my app is for the client to enter a user id and password, and the
server will not proceed without verifying this.
Paul Rubin wrote:
Frank Millman [EMAIL PROTECTED] writes:
I was hoping to avoid this step. The point of the exercise for me is
encryption. I am not too worried about authentication. The next step in
my app is for the client to enter a user id and password, and the
server will not proceed
Frank Millman enlightened us with:
The point of the exercise for me is encryption. I am not too worried
about authentication.
Encryption can't function fully without authenication.
The next step in my app is for the client to enter a user id and
password, and the server will not proceed
Sybren Stuvel wrote:
Frank Millman enlightened us with:
The point of the exercise for me is encryption. I am not too worried
about authentication.
Encryption can't function fully without authenication.
Ok, I have been thinking about the replies from you and Paul, and I am
confused
Frank Millman [EMAIL PROTECTED] writes:
What I have not understood is how to prevent this. How can the client
distinguish between a valid server and a fraudulent one? If it obtains
the server credentials dynamically, the fraudulent server can supply
fraudulent credentials. If somehow the
Frank Millman enlightened us with:
If I understand correctly, a 'man-in-the-middle' attack would
involve someone setting up a 'pseudo server', which gives the
correct responses to the client's attempt to log in
That's right. Usually it's done by proxying the data between the
client and the
Paul Rubin enlightened us with:
for example, OpenSSL (www.openssl.org) comes with a simple Perl
script that acts as a rudimentary CA.
I never understood those CA scripts. I mean, creating a new CA
certificate only has to be done once, and is:
openssl req -new -x509 -key $KEY -out $OUT -days
21 matches
Mail list logo
