Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.14.1.0 2019-05-10T00:16:49Z 2019-05-10T00:16:49Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-05-10T00:16:07Z urn:sha1:9a7a453f258425e4958de45c1db35a9094ec9c35 2019-05-07T10:01:42Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-05-01T22:01:53Z urn: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. 2019-04-26T11:37:15Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2019-04-25T16:35:27Z urn:sha1:5e0da6fb68446612844970be1e862f0e5bc25183 SHA1 is too close to bruteforceable 2019-04-07T17:02:43Z Lee Clagett code@leeclagett.com 2019-04-07T01:28:37Z urn:sha1:2e578b8214b8b47d7ddefceb1cbf2d8129e85a5a If `--daemon-ssl enabled` is set in the wallet, then a user certificate, fingerprint, or onion/i2p address must be provided. 2019-04-07T04:44:37Z Lee Clagett code@leeclagett.com 2019-04-04T17:35:33Z urn: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. 2019-04-07T04:44:37Z Lee Clagett code@leeclagett.com 2019-04-04T05:48:55Z urn: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. 2019-04-07T04:44:37Z Lee Clagett code@leeclagett.com 2019-03-20T05:26:36Z urn: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. 2019-04-07T04:44:37Z Lee Clagett code@leeclagett.com 2019-03-19T20:04:32Z urn: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. 2019-04-07T04:44:37Z Lee Clagett code@leeclagett.com 2019-03-18T02:06:36Z urn:sha1:0416764caec5b2d504c820e71d74a4934c3e2c3e 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. 2019-04-07T04:44:37Z Lee Clagett code@leeclagett.com 2019-03-17T20:11:42Z urn:sha1:96d602ac84d856c26a9065bfccbe2b98237db271 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.