omar-polo / gmid

a Gemini server
https://gmid.omarpolo.com
ISC License
98 stars 8 forks source link

tls error: handshake failed: Success #13

Closed Mihara closed 1 year ago

Mihara commented 2 years ago
Feb 19 20:24:20 aiko gmid: 2607:fea8:4f1f:4c00:4439:56fd:d875:199b:48516 GET  59 Wrong/malformed host or missing SNI
Feb 19 20:24:20 aiko gmid: 2607:fea8:4f1f:4c00:4439:56fd:d875:199b:48516 tls error: handshake failed: Success
Feb 19 20:24:20 aiko gmid: 2607:fea8:4f1f:4c00:4439:56fd:d875:199b:48516 unknown bufferevent error: Success

I'm not sure if this is actually an issue -- for one, I have no idea what's on the other end of this log message, and whether the connection even could succeed -- but I can't help but share this error message and wonder if you could perhaps enlighten me how can a handshake fail successfully. :)

I'm seeing it on average once a day.

omar-polo commented 2 years ago

Hello,

no, it's not really an issue, it just mean that the TLS handshake failed, it's not the end of the world, it can happen if some strange client without SNI tries to connect or if the connection gets interrupted during the handshake phase.

the error reporting is confusing tho, I agree.

The first error is logged by server.c:992 and the "handshake failed: Success" part is what libtls returns. What os are you using? I don't think I've ever seen an error like that on OpenBSD with libressl, maybe it's something from libretls (similar names but different libraries!)

The second error is from server.c and it says "success" because the error code is zero. Now that I think about it, logging the errno value is pretty much useless since libtls zeroes it before returning, I'll drop it.

By the way, I'm seeing that I'm currently handling the handshake in a sub-optimal way, I'm delaying the handshake errors late after virtual domains matching when I could bail out before. I'll look into it.

Thanks :)

Mihara commented 2 years ago

What os are you using?

Gentoo Linux. I didn't make the ebuild myself, so all I can tell you about the libraries it actually gets compiled with is this:

DEPEND="
        !elibc_Darwin? ( dev-libs/libbsd )
        acct-user/gemini
        dev-libs/imsg-compat
        dev-libs/libevent:=
        dev-libs/libretls:=
        dev-libs/openssl:=
"

So I presume that's from libretls.

Thanks :)

Glad I could at least amuse you with it a bit. :)

Toby222 commented 2 years ago

I experienced this too while I was first testing on my RasPi, but I don't recall specifics.

omar-polo commented 1 year ago

Hello, and sorry for the delay. I've only resumed recently to hack again on gmid.

I've fixed this in c5edb15.

The reason was that since handshake failures were handled in a sub-optimal way, gmid tried to reply (via TLS) failing. Those connections were from clients not speaking TLS (or speaking an ancient version), so there's no point in replying and now gmid just shuts down these requests.

It's not a serious bug, gmid just wastes some cycles harmlessly, so I don't think i'll release a bugfix release for this. There's an upcoming 2.0 (no ETA yet) with this and more change anyway.

I'll close this for now, but feel free to reopen or file another issue.

Thanks!