Re: Network security manager

[Lars Magne Ingebrigtsen]

Toke Høiland-Jørgensen <address@hidden> writes:

> Once the fingerprint is stored, though, it fails in weird ways. I tried
> manually modifying the fingerprint in the network-security.data file (to
> make verification fail). This elicits this behaviour:
>
> - On security levels high and paranoid, verification just fails silently
>   (open-network-stream returns nil), with no option to update the stored
>   fingerprint.

I edited a fingerprint, set the level to `high', and then reconnected.
It notified me that it had changed, and then returned the process.  So I
seem to be unable to reproduce this.

This is my test case:

(setq process
      (open-network-stream
       "nntpd" (get-buffer-create "*nntp*") "google.com" "https"
       :type 'tls))

> - On security levels low and medium, verification *succeeds*, even
>   though a fingerprint is stored that does not match the certificate.
>
> I would consider especially the second point to be a big no-no; even if
> the security level is subsequently lowered, having a stored fingerprint
> should take precedence and fail the verification. Maybe the "continue
> anyway" could cause the stored fingerprint to be removed, but just
> continuing regardless is bad IMO.

No I think that's the correct behaviour.  If you want `medium' security,
you only care about whether the certificate is valid or not.  And the
google.com certificate is valid, even though it changed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no