Skip to content

Connection to TLS enabled PD failing #444

Closed
@limbooverlambda

Description

@limbooverlambda

Hi, I have raised this issue in the tikv-wg slack. While running the client we are running into issues where the client fails to connect to a TLS enabled PD endpoint with the error:

[WARN] [config_logging.go:287] ["rejected connection"] [remote-addr="[addr]:port"] [server-name=] [error="tls: first record does not look like a TLS handshake"]

Digging into the code, the problem seems to stem from the following logic in the client (

let addr = "http://".to_string() + &SCHEME_REG.replace(addr, "");
)

let addr = "http://".to_string() + &SCHEME_REG.replace(addr, "");

info!("connect to rpc server at endpoint: {:?}", addr);

let mut builder = Channel::from_shared(addr)?
    .tcp_keepalive(Some(Duration::from_secs(10)))
    .keep_alive_timeout(Duration::from_secs(3));

Here SCHEME_REG is the regex to find "https" in the prefix of the address (

lazy_static::lazy_static! {
).

lazy_static::lazy_static! {
    static ref SCHEME_REG: Regex = Regex::new(r"^\s*(https?://)").unwrap();
}

This is a problem during the ssl handshake since the server is not acknowledging the requests sent to an addressed prefixed with "http" instead of "https". Removing the logic to mutate the address fixed the issue. But I was wondering if someone can shed some light on why it was necessary to strip out "https" from the address and replace those with "http"? Wouldn't it be simpler to make this a passthrough and have the user pass their address as is? I can raise a PR with a fix if this is unintended behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions