monzero-core.git/contrib/epee/src/net_ssl.cpp, branch v0.15.0.1Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.15.0.12019-10-18T18:32:33Zepee: fix SSL server handshake, run_one() can block, use poll_one()2019-10-18T18:32:33Zxiphonxiphon@protonmail.com2019-10-17T02:50:18Zurn:sha1:23ba69ec886ebcb5c529ff22a0c26c50decd1005epee: implement handshake timeout for SSL connections2019-09-17T22:21:16Zxiphonxiphon@protonmail.com2019-09-17T22:19:48Zurn:sha1:4371791977a18653da16a99f41de46cee5fa337bnet_ssl: free certs after setting them up2019-05-10T00:16:49Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-05-10T00:16:07Zurn:sha1:9a7a453f258425e4958de45c1db35a9094ec9c35net_ssl: SSL config tweaks for compatibility and security2019-05-07T10:01:42Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-05-01T22:01:53Zurn:sha1:a62e0725715a7ce2bacf0487379130a402c7a3dd
add two RSA based ciphers for Windows/depends compatibility
also enforce server cipher ordering
also set ECDH to auto because vtnerd says it is good :)
When built with the depends system, openssl does not include any
cipher on the current whitelist, so add this one, which fixes the
problem, and does seem sensible.
change SSL certificate fingerprint whitelisting from SHA1 to SHA-2562019-04-26T11:37:15Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-04-25T16:35:27Zurn:sha1:5e0da6fb68446612844970be1e862f0e5bc25183
SHA1 is too close to bruteforceable
Enabling daemon-rpc SSL now requires non-system CA verification2019-04-07T17:02:43ZLee Clagettcode@leeclagett.com2019-04-07T01:28:37Zurn:sha1:2e578b8214b8b47d7ddefceb1cbf2d8129e85a5a
If `--daemon-ssl enabled` is set in the wallet, then a user certificate,
fingerprint, or onion/i2p address must be provided.
Require manual override for user chain certificates.2019-04-07T04:44:37ZLee Clagettcode@leeclagett.com2019-04-04T17:35:33Zurn:sha1:d58f368289709e0869c9b7927778339670cb85a7
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.
Only check top-level certificate against fingerprint list.2019-04-07T04:44:37ZLee Clagettcode@leeclagett.com2019-04-04T05:48:55Zurn:sha1:97cd1fa98d58fa354ebbade47e894f169ee0c1e2
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.
Call `use_certificate_chain_file` instead of `use_certificate_file`2019-04-07T04:44:37ZLee Clagettcode@leeclagett.com2019-03-20T05:26:36Zurn:sha1:7c388fb3586a1600d1898a6fb6398c675d4bd562
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.
Perform RFC 2818 hostname verification in client SSL handshakes2019-04-07T04:44:37ZLee Clagettcode@leeclagett.com2019-03-19T20:04:32Zurn:sha1:eca0fea45a1fe2eb359c6fff5f5701e0b2fcdc5a
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.