Dmytro Shteflyuk created THRIFT-6098:
----------------------------------------
Summary: Ruby SSLSocket should verify peers by default
Key: THRIFT-6098
URL: https://issues.apache.org/jira/browse/THRIFT-6098
Project: Thrift
Issue Type: Bug
Components: Ruby - Library
Affects Versions: 0.24.0
Reporter: Dmytro Shteflyuk
Assignee: Dmytro Shteflyuk
h2. Background
{{Thrift::SSLSocket}} currently passes its optional
{{OpenSSL::SSL::SSLContext}} to OpenSSL without establishing consistent
client-side peer-verification defaults. Consequently, the resulting behavior
depends on whether and how the caller configured the supplied context.
This differs from {{Thrift::HTTPClientTransport}}, which already enables peer
verification by default.
h2. Proposed behavior
For the Ruby library in 0.25.0, {{Thrift::SSLSocket}} should:
* verify the peer certificate by default;
* apply the same default when no SSL context is supplied or when the caller
supplies a blank {{OpenSSL::SSL::SSLContext}};
* preserve a caller-provided CA file, CA directory, or certificate store;
* use the system certificate store when the context has no configured trust
source;
* continue checking the certificate identity against {{server_hostname}}, or
the connection host when no separate server hostname is supplied; and
* provide an explicit {{verify_peer: false}} option for applications that
intentionally disable peer identity checks.
h2. Compatibility
This is an intentional behavior change for the Ruby library in 0.25.0.
Applications that intentionally connect without peer identity checks must
update their {{Thrift::SSLSocket}} construction to pass {{verify_peer: false}}
explicitly.
Applications that provide their own CA file, CA directory, or certificate store
should continue using those configured trust sources without modification.
h2. Scope
This change is limited to the Ruby {{Thrift::SSLSocket}} transport.
{{Thrift::HTTPClientTransport}} already verifies HTTPS peers by default and
does not require a behavior change. {{Thrift::RackApplication}} is also outside
the scope because TLS negotiation is handled by the Rack server or reverse
proxy before the Rack application receives a request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
