[Bug 71303] indicate the connection's level of security

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Nov 6 05:47:46 PST 2013


https://bugs.freedesktop.org/show_bug.cgi?id=71303

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
Straw-man design:

Connection.Interface.Securable
    property Encrypted : b, readable
        If true, this connection is known to be encrypted to a reasonable
        level. The definition of "reasonable" is intentionally left vague.

        This can change from false to true, but if it would change
        from true to false, connection managers SHOULD disconnect instead.
        Change notification is via o.fd.DBus.Properties.PropertiesChanged.

    property Authenticated : b, readable
        True if this channel occurs over a connection that is
        protected against tampering, and has been verified to be
        with the desired destination: for instance, one where TLS
        was previously negotiated, and the TLS certificate has
        been verified against a configured certificate authority
        or accepted by the user.

        This can change from false to true, but if it would change
        from true to false, connection managers SHOULD disconnect instead.
        Change notification is via o.fd.DBus.Properties.PropertiesChanged.

    property CipherSuiteID : u, readable
        The numeric ID of the cipher suite from the IETF TLS Cipher Suite
        registry, in the form (first byte * 256) + second byte.
        For instance, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC0, 0x09)
        is denoted by 49161 (0xC009).

        0 (TLS_NULL_WITH_NULL_NULL) means the connection
        has no effective security. Connection managers MAY use this
        cipher suite ID to represent known-weak cipher suites
        not described in the TLS Cipher Suite registry.

        The maximum 32-bit unsigned integer (4294967295) means the
        connection manager cannot represent the cipher suite in terms
        of the TLS Cipher Suite registry.

        Change notification is via o.fd.DBus.Properties.PropertiesChanged.

    enum {
        Not_TLS = 0,
        SSL_2 = 2*256,
        SSL_3 = 3*256,
        TLS_1_1 = 3*256 + 1, 
        TLS_1_1 = 3*256 + 2,
        TLS_1_2 = 3*256 + 3,
    } TLS_Version;

    property TLSVersion : u (TLS_Version), readable
        The SSL/TLS version in use, in the form (major byte * 256) +
        minor byte, or 0 if the connection is not using SSL/TLS.
        For instance, TLS 1.1 is 3*256 + 2 due to its use of { 3, 2 }
        as the ProtocolVersion.

        Change notification is via o.fd.DBus.Properties.PropertiesChanged.

    property CertificateType : s
        The type of the certificate used to authenticate the server,
        e.g. "x509" or "pgp", as for TLSCertificate, or the empty
        string if a certificate was not used.

        Change notification is via o.fd.DBus.Properties.PropertiesChanged.

    property CertificateChainData : aay (Certificate_Data[])
        The certificate chain, as for TLSCertificate.

        Change notification is via o.fd.DBus.Properties.PropertiesChanged.

Actually implementing this in Gabble will require some contortions: GNUTLS
doesn't tell us the cipher suite, only separate values for the key exchange,
cipher and MAC. We could maybe replace CipherSuiteID with separate properties,
but I'm really keen to outsource this to something like the IETF TLS registry
rather than maintaining enums in Telepathy.

If we port Wocky to GTLS (which we should really), we lose the ability to get
this information at all, unless we enhance GTLS...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the telepathy-bugs mailing list