Ticket #35 (assigned defect)

Opened 3 years ago

Last modified 10 months ago

security: verify server certificate in the client

Reported by: yvesjm Assigned to: stephan (accepted)
Priority: critical Milestone: 0.2.0
Component: agent Version: 0.1.7
Keywords: Cc:

Description (Last modified by yvesjm)

The client must verify the server certificate before connecting to it.

Instead of trusting in any certificate or, as Jan Suhr pointed out, trusting in any CA-issued certificate, the client should only trust in a specific server certificate.

UPDATE: nah.

  • After the first connection, the client should save the server's certificate (maybe reviewed by the admin)
  • If the cert changes, the connection should not be established

Change History

03/08/06 03:48:32 changed by yvesjm

  • priority changed from major to critical.
  • type changed from enhancement to defect.

05/20/06 16:44:01 changed by yvesjm

  • status changed from new to assigned.
  • description changed.

06/19/06 21:48:29 changed by yvesjm

  • summary changed from Verify server certificate in the client to security: verify server certificate in the client.

09/15/06 01:01:46 changed by yvesjm

In current versions of m2crypto (after sarge) the connection will fail if the commonname of the server does not match the host name it is connecting to.

This is great, but even after I tried really hard, I still could not make cert verify work. I'm trying, I'm trying!

10/01/06 17:07:46 changed by yvesjm

  • milestone changed from 0.3.0 to 0.2.0.

10/04/06 00:46:00 changed by yvesjm

(In [278]) * Started to fix nwu-agent code style (Ref #72) * Started to fix server SSL certificate check (Ref #35)

10/10/06 01:19:56 changed by yvesjm

I am considering the fixed, but during tests, if I changed a few characters in the server private key file, it wouldn't stop the client from verifying the server.

I'll create a new bug for this.

10/10/06 01:23:08 changed by yvesjm

  • status changed from assigned to closed.
  • resolution set to fixed.

10/10/06 01:23:34 changed by yvesjm

See bug #87

02/26/07 14:35:42 changed by yvesjm

  • status changed from closed to reopened.
  • resolution deleted.
  • description changed.

I'd rather do this:

  • DNS fqdn must match the SSL certificate commonName
  • After the first connection, the client should save the server's certificate (maybe reviewed by the admin)
  • If the cert changes, the connection should not be established

01/05/08 14:22:23 changed by stephan

The GnuTLS-enabled client implementation allows us to do this (automagically) by specifying a CA certificate file. See #59 for details.

01/17/08 15:45:54 changed by yvesjm

  • owner changed from yvesjm to stephan.
  • status changed from reopened to new.
  • version set to 0.1.7.

01/17/08 18:04:23 changed by stephan

  • status changed from new to assigned.

01/17/08 19:03:08 changed by stephan

Is there any reason for not trusting a certificate signed by our own CA?

Checking if the server certificate has changed would not do any good when the server certificate expires. This would mean that an administrator has to manually set all clients up again.

As all certificates are signed by the server's CA anyways I think we can trust all of them, as long as they are server certificates.

01/17/08 19:38:23 changed by yvesjm

What if bob, an angry employee, is able to quickly change mary's agent.conf file and make it point to his computer. Then he installs nwu-server there and use the CA-signed certificate as if he was a valid server.

In the current implementation, would this attack work? Or is the server certificate different from a client certificate in a way that prevents such occurrence?

01/17/08 19:44:25 changed by stephan

Those certificates are different, just use give "certtool -i --infile client.crt" and "certtool -i --infile server.crt" a try after nwu-server created those in the initialization phase.

The server certificate is marked as TLS Web Server, the client certificate as TLS Web Client.

So, yes, we are safe from such attacks. In order to change that bit in the certificate one would need direct access to the CA files, which are on the machine running nwu-server. And if you ask me, if someone has access to that machine and those files we cannot do anything about it anyways.

01/17/08 19:46:47 changed by stephan

Mhh, I just checked and noticed that python-gnutls does not provide us with that information. I need to have a closer look at that later on.

01/17/08 20:38:42 changed by stephan

As of [450] code which is able to check the mentioned "markings" is in my branch (source:branches/stephan/nwu/common/gnutlsext.py).

-->