Ошибка рукопожатия TLS от xx.xx.xx.xx:14333: EOF

Я использую HTTPS-сервер в Linux (RHEL 7). Я получаю следующую ошибку, как только запускаю сервер.

2019/09/04 15:46:16 http: TLS handshake error from xx.xx.xx.xx:60206: EOF
2019/09/04 15:46:21 http: TLS handshake error from xx.xx.xx.xx:31824: EOF

Эта ошибка появляется автоматически и постоянно в терминале. Ниже приведен код для создания https-сервера:

package main

import (
    "fmt"
    "net/http"

    "github.com/gin-gonic/gin"
)

func main() {
    fmt.Println("Starting webserver")

    router := gin.Default()
    router.GET("/", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{
            "success": true,
        })
    })

    router.RunTLS(":9001", "server.pem", "server.key")
}

Мы приобрели и объединили сертификат сервера, промежуточный сертификат и корневой сертификат в один файл, чтобы создать файл server.pem.

Поскольку эта ошибка появляется постоянно и в терминале, как только я запускаю сервер, я думаю, что в виртуальной машине есть какая-то проблема с конфигурацией?

Пожалуйста, предложите, что я могу проверить здесь.

ПРИМЕЧАНИЕ. Эта ошибка характерна для Go. Я тестировал на том же сервере на том же порту с теми же сертификатами в Node JS. И это работает нормально. Также IP-адрес в сообщении об ошибке относится к обратному прокси-серверу (WAF), который постоянно выполняет мониторинг работоспособности сервера веб-приложений.


person Sibaprasad Maiti    schedule 04.09.2019    source источник
comment
Используйте openssl s_client -msg или эквивалент, чтобы увидеть полный обмен TLS. Судя по той скудной информации, которую вы даете, одна сторона решила прекратить общение после того, как ей что-то не понравилось.   -  person Patrick Mevzek    schedule 04.09.2019
comment
Дело в том, что когда я нажимаю URL-адрес из браузера моего ноутбука, он работает отлично, без каких-либо ошибок сертификата. Но внутри виртуальной машины эта ошибка постоянно появляется в журнале. Итак, запрос откуда-то приходит, но я не могу понять, как. Моя виртуальная машина Linux работает за прокси-сервером, вот и все, что я знаю. Он находится в облаке IBM. Любые возможности, где этот запрос может прийти автоматически?   -  person Sibaprasad Maiti    schedule 06.09.2019


Ответы (1)


Я бы атаковал проблему с двух сторон:

  1. Что это за xx.xx.xx.xx адрес? Я ожидаю, что когда я запускаю какую-то случайную программу, к ней не будет ничего подключаться само по себе, верно?

  2. Есть ли что-то особенное в этом порте 9001? Попробуйте запустить nc -l -p 9001 и посмотрите, происходят ли эти неопознанные соединения.

    Запустите tcpdump и посмотрите, есть ли какой-либо входящий трафик от клиентов, выполняющих эти соединения: те EOFs (это «конец файла»), о которых сообщает машина TLS, скорее всего, означают, что эти клиенты — кем бы они ни были — закрывают свою сторону соединения где-то посредине. рукопожатие TLS — в то время как сервер ожидает прочитать от них какие-то данные. Это намекает на то, что эти клиенты на самом деле не ожидают увидеть протокол TLS в открываемом ими соединении; и они в значительной степени могут отправить в нем какой-то открытый текст, так что вы сможете его просмотреть.

  3. Поиск в Google «9001 port» намекает на то, что он используется для какого-то протокола «диспетчера служб ETL» — что бы это ни было. Это намеки на то, что трафик на 9001 может быть связан с VoIP.

    Я понятия не имею, что с этим делать, но это может дать вам некоторую информацию для дальнейших исследований.

person kostix    schedule 04.09.2019