Using ssllabs to verify ssl shows error logs on sozu

[gtas843]

When running ssl test from ssllabs, i got this error logs, i dont know if it was my conf problem or i have setup wrong https cert, but i receive A rating from the test, and that means all good. I dont know what this error logs had to do:

ERROR WRK-00 RUSTLS

2024-11-04T06:18:56.608175Z 1730701136608175255 74051 ERROR WRK-01 RUSTLS [01JBTX74Q086X9XF52Q8X9012K - -] Session(sni="a.domain.com", source="source_ip", frontend=10, readiness=I("R-EH")&R("RW--")=M("R---"))

Could not perform handshake: PeerIncompatible(NoKxGroupsInCommon

Could not perform handshake: InappropriateMessage { expect_types: [Handshake], got_type: ChangeCipherSpec

ERROR WRK-01 cannot look up certificate: no SNI from session

Could not perform handshake: PeerIncompatible(NoCipherSuitesInCommon)

Could not perform handshake: General("no server certificate chain resolved")

Could not perform handshake: PeerIncompatible(SignatureAlgorithmsExtensionRequired)

Could not perform handshake: NoApplicationProtocol

Im using cerbot to generate ssl cert certbot certonly --standalone -d a.domain.com

And copied all required certs for https.

My sozu https conf:

[[listeners]]
protocol = "http"
address = "0.0.0.0:80"

[[listeners]]
protocol = "https"
address = "0.0.0.0:443"

tls_versions = ["TLS_V12", "TLS_V13"]
cipher_list = [
"TLS13_AES_256_GCM_SHA384",
"TLS13_AES_128_GCM_SHA256",
"TLS13_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
]

[clusters]

[clusters.Server1]
protocol = "http"
https_redirect = true

frontends = [
{ address ="0.0.0.0:80", hostname = "a.domain.com" },
{ address = "0.0.0.0:443", hostname = "a.domain.com", certificate = "/etc/letsencrypt/live/a.domain.com/cert.pem", key = "/etc/letsencrypt/live/a.domain.com/privkey.pem", certificate_chain = "/etc/letsencrypt/live/a.domain.com/chain.pem" },
]

backends = [
{ address = "127.0.0.1:6128" }
]

Im trying to upload files to my backend server using curl curl -F "file=@test.txt" "https://a.domain.com/upload , but mostly got error logs about Could not perform handshake and can't upload the files. When using other reverse proxys like nginx, envoy, haproxy, everything good and had no problems. Im in the process to migrate all my ends to sozu, but this https error kept holding me.

[Wonshtrum]

Hi! Thanks for your interest in Sozu. The errors generated during the SSL Labs testing seem legitimate. Maybe tagging them "error" is misleading as they are not errors from Sozu, but unexpected behavior from the client. I don't know exactly all the tests conducted by SSL Labs but it wouldn't surprise me if they injected error cases to see how the site handles them.
Could you give us the full line of the error you get with your curl? as well as the result of curl -vvv?

[gtas843]

Here is the dummy demo for my api endpoint, only POST request, you can try send upload request using:
https://fclip.cfd/upload?key=AFT6QZGsx6FJIe9A8xFxIDj6zLb716

I use curl -v -F "file=@C:\Users\madto\Downloads\test.txt" "https://fclip.cfd/upload?key=AFT6QZGsx6FJIe9A8xFxIDj6zLb716"

And it stuck on ssl renegotiated unless i ctrl+c then it will shows on the sozu log.

./sozu start -c sozu.toml

curl -vvv https://fclip.cfd

config

saved_state = "./state.json"
log_level = "info"
log_target = "stdout"
command_buffer_size = 16384
handle_process_affinity = true
connect_timeout = 30
request_timeout = 30
worker_automatic_restart = true
activate_listeners = true

[[listeners]]
protocol = "http"
address = "0.0.0.0:80"

[[listeners]]
protocol = "https"
address = "0.0.0.0:443"

[clusters]

[clusters.afc]
protocol = "http"

frontends = [
  { address ="0.0.0.0:80", hostname = "fclip.cfd" },
  { address = "0.0.0.0:443", hostname = "fclip.cfd", certificate = "/etc/letsencrypt/live/fclip.cfd/cert.pem", key = "/etc/letsencrypt/live/fclip.cfd/privkey.pem", certificate_chain = "/etc/letsencrypt/live/fclip.cfd/chain.pem" },
]

backends  = [
  { address = "0.0.0.0:51222" }
]

[Wonshtrum]

Hi, in your second message, it seems the SSL handshake works, contrary to your first message, in which you said you had an error Could not perform handshake. Did you fix it somehow?
It seems your server correctly answers with 404 and 403 meaning communication can be established through HTTPS.
Testing your curl I have the same behavior: it hangs indefinitely. I don't think it is stuck in SSL renegotiation (at least I can't see anything on the curl side that would indicate it). Everything matches the behavior of a slow-to-answer backend. In local, if I set up a backend that never answers I have the same curl logs. What is surprising to me is that it doesn't seem to time out even after 10 minutes. The default time out for the backend is 60s and it doesn't seem you modified it in your config.
Can you confirm your backend doesn't see the request coming?
I you don't see the request, can you try setting the log_level to debug, then observe the logs for the POST request that doesn't work? A "healthy" request should look like this:

2024-11-07T11:45:43.622799Z 1730979943622799280 2000559 DEBUG WRK-00    sozu_lib::https HTTP::upgrade
2024-11-07T11:45:43.622843Z 1730979943622843654 2000559 DEBUG WRK-00    sozu_lib::https Successful TLS Handshake with, received: Some("fclip.cfd") Some("http/1.1")
2024-11-07T11:45:43.622944Z 1730979943622944193 2000559 DEBUG WRK-00    sozu_lib::protocol::kawa_h1     KAWA-H1      [01JC373N5VY23GG2248W39V04Q - -]        Session(public=0.0.0.0:8443, session=127.0.0.1:37708, frontend=6, readiness=I("R-EH")&R("RW--")=M("R---"), backend=<none>, readiness=I("----")&R("----")=M("----"))   >>> Read 83 bytes
2024-11-07T11:45:43.623164Z 1730979943623164688 2000559 DEBUG WRK-00    sozu_lib::backends      Connecting MyCluster -> (127.0.0.1:1026, 0, 1)
2024-11-07T11:45:43.623405Z 1730979943623405741 2000559 DEBUG WRK-00    sozu_lib::protocol::kawa_h1     KAWA-H1      [01JC373N5VY23GG2248W39V04Q MyCluster the-backend-to-my-app]    Session(public=0.0.0.0:8443, session=127.0.0.1:37708, frontend=6, readiness=I("R-EH")&R("-W--")=M("----"), backend=7, readiness=I("RWEH")&R("-W--")=M("-W--"))     >>> Wrote 253 bytes

The general flow should be:

• HTTP::upgrade
• Successful TLS Handshake (with your SNI and ALPN protocol)
• KAWA-H1 Read the number of bytes of your requests
• Connection to a cluster (afc in your case) and a specific backend ip (0.0.0.0:51222 in your case)
• KAWA-H1 Wrote the number of bytes of your requests (plus the headers Sozu appends)
• if you see other Read/Wrote after this it should be your backend answering

I'm curious if Sozu successfully connects to your backend and if it writes all the bytes to it.