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 wheel
"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
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
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 s
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
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 f
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 wi
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 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" <[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-t
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
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 3
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 r
"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 th
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 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 w
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
"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 verifyin
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
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 o
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
21 matches
Mail list logo
