This bug affects windows builds, too. mingw-virt-viewer-0.5.3-16 mingw-spice-gtk-0.12-9 +++ This bug was initially created as a clone of Bug #871034 +++ Description of problem: if CN matches hostname/IP but not explicitly set host subject, the connection should fail. The reason is that externally-provided host subject is likely to be more trustworthy than just check for host/ip == CN equivalence. OpenVPN behaves the suggested way for instance. Version-Release number of selected component (if applicable): spice-gtk-0.14-4.el6.x86_64 windows builds affected too How reproducible: always Steps to Reproduce: 1. have a server with 'CN=server.example.org' in its subject 2. connect to a server: remote-viewer --spice-ca-file=file --spice-host-subject='CN=something-else' spice://server.example.org/?tls-port=sport 3. Actual results: r-v connects Expected results: r-v should print host-subject mismatch error and exit Additional info:
Spice client has always done ssl verify callback by validating any of pubkey, hostname, or subject. I don't know if it's on purpose or a mistake, and I am afraid we are not SSL experts. Since we have few SSL good practices experience, do you have that openvpn reference or any other information to help us understand and do the right move?
(In reply to comment #3) > Spice client has always done ssl verify callback by validating any of > pubkey, hostname, or subject. I don't know if it's on purpose or a mistake, > and I am afraid we are not SSL experts. > > Since we have few SSL good practices experience, do you have that openvpn > reference or any other information to help us understand and do the right > move? open and OpenVPN connection to name-based gateway in nm-connection editor, go to "VPN" tab, press "Advanced..." button, go to "TLS Authentication", overwrite "Subject Match:" field with nonsense string. Save and try to connect, you should get something like this in /var/log/messages: May 2 17:06:50 cihla nm-openvpn[8442]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed May 2 17:06:50 cihla nm-openvpn[8442]: TLS Error: TLS object -> incoming plaintext read error May 2 17:06:50 cihla nm-openvpn[8442]: TLS Error: TLS handshake failed in spite of the subject matching DNS name. That said, if we follow default openvpn trust settings, we should verify only user-defined subject when defined.
I've sent a potential patch for this to http://lists.freedesktop.org/archives/spice-devel/2013-September/014612.html. Btw, I'm confused by your 'but not explicitly set host subject' in the bug description, as the example you give has an explicitly set host subject. I assume you mean 'but does not match explicitly set host subject' ?
Yes, that's what I meant.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0644.html