Блог

Мы настраивали SSL для веб-сайта rskolkata.com . Сначала мы настроили Cloudflare для сайта. На сайте Cloudflare все было в порядке, включая настройки DNS-сервера. Однако произошло нечто, повредившее SSL-сертификаты по всей сети. Мы пытались получить доступ к веб-сайту в ubuntu 20.10 и Windows 10 на всех компьютерах в сети во всех браузерах (Chrome, Mozilla, Opera) как в обычном режиме, так и в режиме инкогнито. Мы всегда получаем ошибку ERR_SSL_PROTOCOL_ERROR в Chrome и в Mozilla, ошибка SSL_ERROR_INTERNAL_ERROR_ALERT . Мы попробовали следующую команду в Ubuntu:

sudo apt-get install --reinstall ca-certificates

Это сработало на компьютере (скажем, на компьютере A) за пределами затронутой сети (но на том же компьютере, который изначально был в поврежденной сети). Когда мы попробовали ту же команду на компьютерах Ubuntu в зараженной сети, она не сработала. Мы также пытались очистить состояние SSL в Chrome на компьютере с Windows, но это не сработало. Затем мы попробовали следующее:

 sudo apt-get -f install
# stop if you saw any errors

sudo dpkg --purge --force-depends ca-certificates
sudo apt-get -f install
 

Мы попробовали выше, что также не помогло решить проблему.

Веб-сайт открывается без каких-либо проблем за пределами уязвимой сети.

Мы проверили статус веб-сайта на веб-сайте https://www.websiteplanet.com/webtools / который показывает, что сайт запущен. SSL работает правильно.

«Машина A» при повторном подключении к уязвимой сети снова начинает выдавать ошибку.

Однако, поскольку мы являемся разработчиком сайта, нам необходимо получить доступ к сайту из нашей офисной сети. Пожалуйста, предложите решение.

ОБНОВЛЕНИЕ 1:

Ctrl Shift K в firefox выдает An error occurred: SSL_ERROR_INTERNAL_ERROR_ALERT

$ curl -vk https://rskolkata.com

Вывод:

 *   Trying 151.106.116.81:443...
* TCP_NODELAY set
* Connected to rskolkata.com (151.106.116.81) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

 

‘копать rskolkata.com ` дает следующий результат:

  dig rskolkata.com

; <<>> DiG 9.16.6-Ubuntu <<>> rskolkata.com
;; global options:  cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29471
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;rskolkata.com.         IN  A

;; ANSWER SECTION:
rskolkata.com.      6794    IN  A   151.106.116.81

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Jan 22 14:25:50 IST 2021
;; MSG SIZE  rcvd: 58

 

И и dig trace rskolkata.com выдает следующий вывод:

 ; <<>> DiG 9.16.6-Ubuntu <<>>  trace rskolkata.com
;; global options:  cmd
.           238434  IN  NS  k.root-servers.net.
.           238434  IN  NS  b.root-servers.net.
.           238434  IN  NS  h.root-servers.net.
.           238434  IN  NS  j.root-servers.net.
.           238434  IN  NS  e.root-servers.net.
.           238434  IN  NS  m.root-servers.net.
.           238434  IN  NS  c.root-servers.net.
.           238434  IN  NS  f.root-servers.net.
.           238434  IN  NS  d.root-servers.net.
.           238434  IN  NS  a.root-servers.net.
.           238434  IN  NS  g.root-servers.net.
.           238434  IN  NS  i.root-servers.net.
.           238434  IN  NS  l.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 3 ms

rskolkata.com.      12530   IN  A   151.106.116.81
rskolkata.com.      72951   IN  NS  ns1.dns-parking.com.
rskolkata.com.      72951   IN  NS  ns2.dns-parking.com.
;; Received 222 bytes from 199.7.91.13#53(d.root-servers.net) in 0 ms

 

Сервер имен DNS dimitris.ns.cloudflare.com и IP 172.67.138.143 , как видно на https://mxtoolbox.com /

Попробуйте посмотреть на веб-консоль разработчика (firefox Ctrl Shift K) — что-нибудь интересное на вкладке Безопасность?

Попробуйте запустить curl -vk https://rskolkata.com — что это показывает?

Поскольку кажется, что вы тестируете веб-сайт из office, где вы также его разрабатываете, возможно, ваш сетевой администратор настроил «что-то особенное», чтобы помочь с тестированием? dig rskolkata.com Возвращают ли dig trace rskolkata.com оба ожидаемых IP-адреса?

Редактировать: попробуйте перехватить трафик с помощью tcpdump (например tcpdump -nni eth0 host DESTIP -w trace.pcap ), затем откройте trace.pcap в wireshark и сравните рабочий и нерабочий случай. Возможно, будет какая-то разница.

Вы сказали, небольшая команда. Тогда, я думаю, между локальной сетью в Интернете нет модного промежуточного блока, который мог бы что-то сделать с SSL-рукопожатием.

Вы можете переместить свой тестовый клиент из локальной сети «ближе» к Интернету. Меняется ли это, когда между вами и Интернетом на один GW / FW меньше? Я предполагаю, что это может быть связано с сетевым оборудованием в вашей компании или сетевым оборудованием вашего интернет-провайдера.