Skip to content
Permalink
Branch: master
Commits on Apr 7, 2019
  1. Enabling daemon-rpc SSL now requires non-system CA verification

    vtnerd committed Apr 7, 2019
    If `--daemon-ssl enabled` is set in the wallet, then a user certificate,
    fingerprint, or onion/i2p address must be provided.
  2. Require manual override for user chain certificates.

    vtnerd committed Apr 4, 2019
    An override for the wallet to daemon connection is provided, but not for
    other SSL contexts. The intent is to prevent users from supplying a
    system CA as the "user" whitelisted certificate, which is less secure
    since the key is controlled by a third party.
  3. Only check top-level certificate against fingerprint list.

    vtnerd committed Apr 4, 2019
    This allows "chain" certificates to be used with the fingerprint
    whitelist option. A user can get a system-ca signature as backup while
    clients explicitly whitelist the server certificate. The user specified
    CA can also be combined with fingerprint whitelisting.
  4. Call `use_certificate_chain_file` instead of `use_certificate_file`

    vtnerd committed Mar 20, 2019
    The former has the same behavior with single self signed certificates
    while allowing the server to have separate short-term authentication
    keys with long-term authorization keys.
  5. Perform RFC 2818 hostname verification in client SSL handshakes

    vtnerd committed Mar 19, 2019
    If the verification mode is `system_ca`, clients will now do hostname
    verification. Thus, only certificates from expected hostnames are
    allowed when SSL is enabled. This can be overridden by forcible setting
    the SSL mode to autodetect.
    
    Clients will also send the hostname even when `system_ca` is not being
    performed. This leaks possible metadata, but allows servers providing
    multiple hostnames to respond with the correct certificate. One example
    is cloudflare, which getmonero.org is currently using.
  6. Require server verification when SSL is enabled.

    vtnerd committed Mar 18, 2019
    If SSL is "enabled" via command line without specifying a fingerprint or
    certificate, the system CA list is checked for server verification and
    _now_ fails the handshake if that check fails. This change was made to
    remain consistent with standard SSL/TLS client behavior. This can still
    be overridden by using the allow any certificate flag.
    
    If the SSL behavior is autodetect, the system CA list is still checked
    but a warning is logged if this fails. The stream is not rejected
    because a re-connect will be attempted - its better to have an
    unverified encrypted stream than an unverified + unencrypted stream.
  7. Add `verify_fail_if_no_cert` option for proper client authentication

    vtnerd committed Mar 17, 2019
    Using `verify_peer` on server side requests a certificate from the
    client. If no certificate is provided, the server silently accepts the
    connection and rejects if the client sends an unexpected certificate.
    Adding `verify_fail_if_no_cert` has no affect on client and for server
    requires that the peer sends a certificate or fails the handshake. This
    is the desired behavior when the user specifies a fingerprint or CA file.
  8. Change default SSL to "enabled" if user specifies fingerprint/certifi…

    vtnerd committed Mar 14, 2019
    …cate
    
    Currently if a user specifies a ca file or fingerprint to verify peer,
    the default behavior is SSL autodetect which allows for mitm downgrade
    attacks. It should be investigated whether a manual override should be
    allowed - the configuration is likely always invalid.
  9. Do not require client certificate unless server has some whitelisted.

    vtnerd committed Mar 12, 2019
    Currently a client must provide a certificate, even if the server is
    configured to allow all certificates. This drops that requirement from
    the client - unless the server is configured to use a CA file or
    fingerprint(s) for verification - which is the standard behavior for SSL
    servers.
    
    The "system-wide" CA is not being used as a "fallback" to verify clients
    before or after this patch.
  10. Change SSL certificate file list to OpenSSL builtin load_verify_location

    vtnerd committed Mar 12, 2019
    Specifying SSL certificates for peer verification does an exact match,
    making it a not-so-obvious alias for the fingerprints option. This
    changes the checks to OpenSSL which loads concatenated certificate(s)
    from a single file and does a certificate-authority (chain of trust)
    check instead. There is no drop in security - a compromised exact match
    fingerprint has the same worse case failure. There is increased security
    in allowing separate long-term CA key and short-term SSL server keys.
    
    This also removes loading of the system-default CA files if a custom
    CA file or certificate fingerprint is specified.
You can’t perform that action at this time.