решения.
В общем имеется древний проприетарный TCP-сервер использующий stateful-протокол (важно). После TCP-подключения необходимо установить TLS-сессию (поддерживается только v1.0). По факту это обыкновенный TLS over TCP.
Средствами Go это достигается достаточно легко:
conn, err := net.Dial("tcp", addr)
if err != nil {
return nil, fmt.Errorf("error while dialing: %w", err)
}
tlsConn := tls.Client(conn, &tls.Config{
InsecureSkipVerify: true,
})
И оно работает, но увы крайне ненадёжно: установленное TLS-соединение норовит разрываться с EOF абсолютно рандомно. Иногда достаточно подождать секунду, иногда минуту, но в целом если начинать слать в канал много сообщений, то разрыв происходит стабильно быстро (в течении нескольких секунд после установления).
После продолжительного ресёрча и копания интернетов, было не придумано ничего лучше, чем попробовать взять OpenSSL для TLS-сессии, в итоге получилось вот так:
sslCtx, err := openssl.NewCtxWithVersion(openssl.TLSv1)
if err != nil {
return nil, fmt.Errorf("error while initializing OpenSSL context: %w", err)
}
tlsConn, err := openssl.Dial("tcp", addr, sslCtx, openssl.InsecureSkipHostVerification)
if err != nil {
return nil, fmt.Errorf("error while dialing: %w", err)
}
Так соединение совершенно стабильно и никогда не разрывается. Возникает вопрос: почему с OpenSSL всё работает стабильно, а с нативным Go-клиентом нет? Я не исключаю, что эта проприетарщина просто криво написана, но по-моему это всё равно немного странно.
Собственно никто ли не сталкивался с таким? Есть ли для этого решения? Если баг на стороне Go, то я даже не знаю как заводить issue. В логах проприетарщины в момент разрыва прилетает errno: 11 (она написана на C), причём не уточняется это EAGAIN или EWOULDBLOCK.
Очень необычно
Спустя 3 месяца нашёл решение своей проблемы: Сервер был настолько стар, что там нет патча от атаки BEAST. Обновить его возможности нет. Пришлось сделать форк crypto/tls и добавить возможность выключить этот патч. После этого проблему как рукой сняло.
Обсуждают сегодня