Пройдя по всем аспектам и особенностям сетевых протоколов в Linux, в заключительной главе хочется упомянуть вопрос безопасности данных протоколов, их историю и способы защиты систем от внешних воздействий.
Что есть безопасность
В рамках разговора о сетях безопасность данных распадается на две составляющие - надёжность и секретность.
Поскольку структура сети изначально не подразумевалась быть настолько масштабной, её разумное построение и совершенствование пришло с опозданием от появления множества проблем в сфере надёжности передачи.
Повышение ==надёжности== сети может обеспечиватся разными методами. Например, повышение связности позволяет использовать для передачи больше маршрутов, что снижает среднюю нагруженность и помогает избежать некоторого числа коллизий.
Для обеспечения передачи с заявленными параметрами сети (скорость, качество соединения) используются средства по резервированию ресурсов сети. В более простом случае без резервирования также помогает overprovisioning - избыточность каналов передачи (условно, среда с пропускной способностью в 1 Гбит/с для обеспечения передачи в 200 Мбит/с, и т.д.).
Для больших систем с большим потоком входящих и исходящих данных используются репликация и “приближение” серверов. Примером этому могут служать крупные DNS-серверы (1.1.1.1, 8.8.8.8 etc.), расположенные по всему миру, доступ к которым максимально приближен к конечным пользователям (по такой же логике работают, к слову, игровые компании; во время обновлений миллионы пользователей единовременно могут скачивать гигабайты новых данных игр, и для устранения глобального зависания сети серверы с обновлениями приближены к устройствам игроков по всему миру).
В мировой сети отлично работает закон больших чисел, поэтому для обеспечения надёжности ведутся разработки по обеспечению надёжности для надёжных протоколов, например, утилита по восстановлению потерянных TCP-пакетов (да, на миллионах пользователей протокол не оказывается стопроцентно надёжным).
Говоря о ==секретности== в сети, возникает две глобальные проблемы - проблема аутентичности данных (определения абонента в сети) и проблема скрытия данных. На данный момент существует множество сетевых атак, направленных так или иначе на эти два аспекта секретности. Самые простые из них направлены на порчу канала или отказ работы сервиса (DOS - Deny Of Service). Атаки, направленные на данные непосредственно, разделяются на два аспекта: чтение и деанонимизация пользователя и содержимого передаваемых данных и модификация или полная подмена данных в сети.
История сетевых протоколов в свете защиты данных
Нельзя не обратиться к истории развития безопасности в сетевых протоколах. Как минимум, потому что до сих пор большинство протоколов наполнены всеми старыми технологиями.
Первые версии протоколов, для которых была важна безопасность, рассматривали только её надёжностную составляющую, не задумываясь о сокрытии данных даже в случае аутентификаций и идентификаций пользователей. Передача файлов по FTP, доступ к почте через SMTP и POP, все они могли быть отловлены простым подслушиванием каналов передачи (для этого даже была специальная утилита dsniff).
Следующим шагом стало использование наивных методов шифрования, например, обмен ключами шифрования в начале сеанса. Здесь появилась (и, вообще говоря, до сих пор преследует всю разработку в сфере обеспечения безопасности передачи) проблема “прозрачного” обмена ключами: необходимо передать пользователю ключ для шифрования данных, при этом шифровать его нельзя, поскольку у пользователя нет ключа для расшифровки. Для некоторых протоколов шифрования такой проблемы не стояло, однако это резко ограничивало их использование. Так, например, придуманный на заре развития шифрования MIT-MAGIC-COOKIE-1 до сих пор используется для использования в строго локальной сети, поскольку ключи шифрования просто записываются в специальный файл, и, вообще говоря, могут быть перемещены туда даже вручную.
При встраивании протоколов шифрования в общий стек также возникает проблема: если для модели ISO/OSI есть отдельный уровень (уровень представления) между сеансом связи и прикладным приложением, на котором осуществляется шифрование (на такой модели строилась первая версия сокетного криптографического протокола SSL-1.0), в TCP/IP протоколы безопасности можно либо привязать к прикладному уровню, либо сразу к транспортному. В первом случае (например, в HTTPS) для проверки корректности просматривается принадлежность ключа шифрования тому сервису (с тем доменным именем, к которому происходит обращение), к которому происходит запрос. Для транспортного уровня (например, протокол TLS) всё сложнее: для проверки сервиса необходимо иметь информацию о сервисе и, соответсвенно, доступ к нему. Но на транспортном уровне для обработки доступен только чистый IP-адрес. Соответственно, криптографический протокол транспортного уровня должен уметь просматривать содержимое, определять сервис-получателя и проводить анализ данных. В случае современных протоколов это не было большой проблемой, однако старые протоколы также нуждались в защите. Для этого наряду с разделёнными появились промежуточные протоколы (например, STARTTLS), встраиваемые в старые протоколы в виде надстроек, к которым происходит обращение в процессе работы.
Вместе с современными протоколами шифрования пришла также тенденция использования ассиметричного шифрования. Такая схема для использования в сети показала себя гораздо лучше симметричного шифрования одним ключом.
Нельзя не упомянуть и не самые удачные схемы шифрования, как, например, шифрованное содержимое пакетов в IPsec, не работающее без туннелирования с другими протоколами (например, с NAT, работа которого подразумевает, в том числе, просматривание содержимого пакета). Кроме этого, такая схема шифрования без шифрованных туннелей позволяет простым пассивным анализом трафика и сбором небольшого количества данных подобрать ключи дешифрации стандартных протоколов, структура которых поддаётся простой логике.
Симметричное шифрование
Чуть подробнее обсудим особенности симметричного шифрования. Основная логика - использование одного ключа для шифровки и дешифровки передаваемой информации. Передача информации в таком случае разбивается на два блока - зашифрованная посылка и ключ от неё. Проблема заключается в кратно возрастаемом риске утечки ключа при каждой его передаче (вследствие, в том числе, PEBKAC-ошибок), а также в отсутствии аутентичности пользователей.
Успешное использование симметричного шифрования наблюдается при аутентификации в сервисах с применением дайжестов - невосстановимых хешей достаточно большого размера. Одним из примеров такой аутентификации выступает HTTP Digest Access Authentification. Сервером пользователю отправляется специальный одноразовый ключ Nonce. Пользователь и сервер (Важно: они должны обладать одинаковой полной информацией для проверки) формируют структуру из учётных данных и ключа, после генерируют по ней дайжест, и пользователь передаёт его серверу. При совпадении данных хеша доступ разрешается.
Ассиметричное шифрование
Схема с использованием двух паролей парного использования (одним (любым из) проводится шифрование, а вторым - дешифровка сообщения) пришла в конце 70-х годов трём разным группам учёных. Протокол Диффи-Хеллмана и протокол RSA основаны на особенностях вычислений над простыми числами, и позволяют построить физически практически невзламываемые криптографические ключи.
Ключи в асимметричном шифровании делятся на закрытый - доступный только пользователю и никому никуда никогда не передающийся - и открытый, который лежит в свободном доступе для всех пользователей. Для обеспечения секретности передачи данных они шифруются открытым ключом получателя, тогда только он своим закрытым ключом сможет получить к ним доступ. При аутентификации (т.н. цифровая подпись) сообщение шифруется закрытым ключом отправителя, тогда любой может убедиться, что именно тот пользователь является отправителем, открыв сообщение его открытым ключом.
При работе с асимметричным шифрованием на текущий момент нерешённой остаётся проблема Man-in-the-middle attack, возникающая, когда пользователям изначально неизвестны открытые ключи друг друга. В таком случае абонент, контролирующий трафик, может перехватить передачу между пользователями, представив свои ключи их ключами, и иметь полный доступ к передаваемым данным.
SSL-сертификаты и цепочка доверия
Для решения проблемы передачи открытых ключей необходимо было придумать способ аутентификации действительной принадлежности получаемого ключа интересующему нас источнику. Самый простой и безопасный способ - при установке дистрибутива сразу сохранять все открытые ключи ко всем ресурсам. Поскольку количество абонентов и сервисов в сети огромно, и собрать полный набор ключей не представляется возможным, была придумана схема с цепочкой доверия и сертификатами. Сертификат представляет из себя список открытых ключей проверенных абонентов-организаций, у которых абоненты-сервисы подтвердили себя в сети (с помощью, н-р, электронной подписи). Таким образом, при получении незнакомого открытого ключа пользователь обращается к сертифицированным организациям, которые возвращают ответ, действительно ли полученный ключ принадлежит интересуемому сервису-источнику.
Список известных организаций хранится в специальных файлах системы. При этом существует возможность генерации собственных сертификатов. Попробуем воспроизвести проверку с помощью сертификата на небольшом стенде:
papillon_rouge: vbintnets
srv:
eth1: intnet
router:
eth1: intnet
eth2: deepnet
client:
eth1: deepnet
papillon_rouge:
Небольшая самостоятельная работа: для последующей настройки потребуется установка последней версии openssl. Для этого необходимо будет подключиться к репозиторию sisyphus от ALT Linux Team, поэтому необходимо обеспечить выход в интернет на srv и client
Предлагается самостоятельно настроить систему. Проверка работоспособности системы - корректная работа данного запроса:
client
[root@client ~]# ping -fc5 ww.ru
PING ww.ru (172.67.177.66) 56(84) bytes of data.
--- ww.ru ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 14ms
rtt min/avg/max/mdev = 2.861/3.376/4.654/0.650 ms, ipg/ewma 3.583/3.988 ms
[root@client ~]#
Не забудьте:
- Настроить маршруты по умолчанию между абонентами
- Настроить трансляцию адресов на выходной машине
- Добавить поддержку
DNS
После настройки выполните установку пакетов:
srv
[root@srv ~]# apt-repo set sisyphus
[root@srv ~]# apt-get install openssl
<...>
[root@srv ~]#
client
[root@client ~]# apt-repo set sisyphus
[root@client ~]# apt-get install openssl
<...>
[root@client ~]#
Для начала создадим администратора, который будет подписывать сертификаты. В нашем случае его будет играть srv, как и роль сервера, подписывающего заявление. В реальности, абонент-администратор должен быть установлен отдельной машиной и строго контролироваться.
Первое действие генерация закрытого ключа для администратора
srv
[root@srv ~]# openssl genrsa -out rootCA.key
[root@srv ~]# ls
bin rootCA.key tmp
[root@srv ~]# cat rootCA.key
-----BEGIN PRIVATE KEY-----
<...>
-----END PRIVATE KEY-----
[root@srv ~]#
На основе закрытого ключа делается открытый ключ-сертификат, которым будет подписываться сервер.
srv
[root@srv ~]# openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt -batch
# Сертификат на основе закрытого ключа со сроком годности 1024 дня
[root@srv ~]# cat rootCA.crt
-----BEGIN CERTIFICATE-----
MIIC+DCCAeCgAwIBAgIUPpJnei28t4YXH8PcmxB+KTUBSIowDQYJKoZIhvcNAQEL
BQAwDTELMAkGA1UEBhMCUlUwHhcNMjUwNjA4MTQzNjMyWhcNMjgwMzI4MTQzNjMy
WjANMQswCQYDVQQGEwJSVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJPt2pewdUiR9aDwfiNWOTA6qRVHck+6oGyYsYzY/6w2KA46c6INfJSZzsu1VUjf
EfxzAlPCQmkh9sRrc10uAj8jU1rFRKAwUzh8vnb5BpTNJM434xzInOri2jQVUG7j
Y/Kvk/w15TxjBM7hQmpjZ15bcEXvbEhJl0FxW+glm9hX4hrMj4jRcNYB9N4tzzYR
IHIX1m2CEuUVVnaWWDwltWIXMjK9lNgN0PlkIpJ/jbdgiD5nj32jYqSs4hN49jZe
4L5kkS1WMdGWr+J5aLghYrpWCVdpChRJlEjDllfJ/hpWyFFz7cK26gSfJreTq2iC
+mVZT9EaG9fDEmCsj6BTD3UCAwEAAaNQME4wHQYDVR0OBBYEFDM2DiABY8x54FWl
0PKBKLmdRwCHMB8GA1UdIwQYMBaAFDM2DiABY8x54FWl0PKBKLmdRwCHMAwGA1Ud
EwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHKfErGh3DUZJpxv4ieb7MIpa3Qo
jmyIYmDlpG3ihEqf4SJd0oggIAnpFLUP0EmDWZXn8uDbRPB51dfOZNQhF1gLEVQ1
9of/Mu6pD3hN+M0XbKcForINaceB99Wr/Rl1ttQUPllDZ2bwgJq06jk3nXS9aiSN
+vQJkPW3+3dfJ0bQyPafIcixgRa0oSxZSK60Ts+5gq4jH/bO2x/E2NgDQub161d8
WYTa6MK1PGB3H7IWzosGEPTepWXNfQd0AqFojPLVNO3Se612xYH/d6VvonE6Tedj
s/BQoOsGF/R3y0NEXZaf04pXIabUnwNbwWn3NMmFkqfQJyVcaCW4vEPl4fU=
-----END CERTIFICATE-----
[root@srv ~]#
Сертификат можно деанонимизировать и прочитать его параметры:
srv
[root@srv ~]# openssl x509 -noout -text -in rootCA.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
3e:92:67:7a:2d:bc:b7:86:17:1f:c3:dc:9b:10:7e:29:35:01:48:8a
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RU
Validity
Not Before: Jun 8 14:36:32 2025 GMT
Not After : Mar 28 14:36:32 2028 GMT
Subject: C=RU
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:93:ed:da:97:b0:75:48:91:f5:a0:f0:7e:23:56:
39:30:3a:a9:15:47:72:4f:ba:a0:6c:98:b1:8c:d8:
ff:ac:36:28:0e:3a:73:a2:0d:7c:94:99:ce:cb:b5:
55:48:df:11:fc:73:02:53:c2:42:69:21:f6:c4:6b:
73:5d:2e:02:3f:23:53:5a:c5:44:a0:30:53:38:7c:
be:76:f9:06:94:cd:24:ce:37:e3:1c:c8:9c:ea:e2:
da:34:15:50:6e:e3:63:f2:af:93:fc:35:e5:3c:63:
04:ce:e1:42:6a:63:67:5e:5b:70:45:ef:6c:48:49:
97:41:71:5b:e8:25:9b:d8:57:e2:1a:cc:8f:88:d1:
70:d6:01:f4:de:2d:cf:36:11:20:72:17:d6:6d:82:
12:e5:15:56:76:96:58:3c:25:b5:62:17:32:32:bd:
94:d8:0d:d0:f9:64:22:92:7f:8d:b7:60:88:3e:67:
8f:7d:a3:62:a4:ac:e2:13:78:f6:36:5e:e0:be:64:
91:2d:56:31:d1:96:af:e2:79:68:b8:21:62:ba:56:
09:57:69:0a:14:49:94:48:c3:96:57:c9:fe:1a:56:
c8:51:73:ed:c2:b6:ea:04:9f:26:b7:93:ab:68:82:
fa:65:59:4f:d1:1a:1b:d7:c3:12:60:ac:8f:a0:53:
0f:75
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
33:36:0E:20:01:63:CC:79:E0:55:A5:D0:F2:81:28:B9:9D:47:00:87
X509v3 Authority Key Identifier:
33:36:0E:20:01:63:CC:79:E0:55:A5:D0:F2:81:28:B9:9D:47:00:87
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
72:9f:12:b1:a1:dc:35:19:26:9c:6f:e2:27:9b:ec:c2:29:6b:
74:28:8e:6c:88:62:60:e5:a4:6d:e2:84:4a:9f:e1:22:5d:d2:
88:20:20:09:e9:14:b5:0f:d0:49:83:59:95:e7:f2:e0:db:44:
f0:79:d5:d7:ce:64:d4:21:17:58:0b:11:54:35:f6:87:ff:32:
ee:a9:0f:78:4d:f8:cd:17:6c:a7:05:a2:b2:0d:69:c7:81:f7:
d5:ab:fd:19:75:b6:d4:14:3e:59:43:67:66:f0:80:9a:b4:ea:
39:37:9d:74:bd:6a:24:8d:fa:f4:09:90:f5:b7:fb:77:5f:27:
46:d0:c8:f6:9f:21:c8:b1:81:16:b4:a1:2c:59:48:ae:b4:4e:
cf:b9:82:ae:23:1f:f6:ce:db:1f:c4:d8:d8:03:42:e6:f5:eb:
57:7c:59:84:da:e8:c2:b5:3c:60:77:1f:b2:16:ce:8b:06:10:
f4:de:a5:65:cd:7d:07:74:02:a1:68:8c:f2:d5:34:ed:d2:7b:
ad:76:c5:81:ff:77:a5:6f:a2:71:3a:4d:e7:63:b3:f0:50:a0:
eb:06:17:f4:77:cb:43:44:5d:96:9f:d3:8a:57:21:a6:d4:9f:
03:5b:c1:69:f7:34:c9:85:92:a7:d0:27:25:5c:68:25:b8:bc:
43:e5:e1:f5
[root@srv ~]#
Теперь создадим закрытый ключ для сервера и подпишем на его основе сертификат. Сначала на основе ключа генерируется запрос на создание сертификата с указанием имени абонента (в нашем случае - его IP-адрес), а затем сам сертификат:
srv
[root@srv ~]# openssl genrsa -out srv.key
[root@srv ~]# openssl req -new -key srv.key -out srv.csr -subj '/CN=10.9.0.26/'
[root@srv ~]# openssl x509 -req -in srv.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out srv.crt -days 365 -sha256
Certificate request self-signature ok
subject=CN=10.9.0.26
Создадим небольшой socat-сервис и попробуем к нему подключиться без наличия сертификата у пользователя.
srv
[root@srv ~]# socat OPENSSL-LISTEN:1234,reuseaddr,fork,cert=srv.crt,key=srv.key,verify=0 EXEC:/usr/bin/
cal
Напомним:
reuseaddr- переиспользование адреса при переподключении к серверу без ожидания закрытия сокета;fork- генерация сыновьего процесса-обработчика для продолжения прослушивания канала (обеспечение множественного подключения к сервису);cert, key- параметры сертификата (для пользователя) и ключа (для подтверждения электронной подписи сервиса);verify=0- от пользователя не будет требоваться подтверждение через его сертификат (иначе дляclientнужна была бы та же цепочка действий).
client
[root@client ~]# socat OPENSSL:10.9.0.26:1234 -
2025/06/08 14:59:41 socat[944] E SSL_connect(): error:0A000086:SSL routines::certificate verify failed
[root@client ~]#
srv
[root@srv ~]# socat OPENSSL-LISTEN:1234,reuseaddr,fork,cert=srv.crt,key=srv.key,verify=0 EXEC:/usr/bin/
cal
2025/06/08 14:59:41 socat[1185] E SSL_accept(): error:0A000418:SSL routines::tlsv1 alert unknown ca
[root@srv ~]#
Очевидно, проверка сертификата прошла неуспешно. Передадим на client сертификат srv и повторим операцию
srv
[root@srv ~]# cat /etc/openssh/sshd_config
PermitRootLogin yes
[root@srv ~]#
client
[root@client ~]# ssh 10.9.0.26
Last login: Sun Jun 8 15:08:37 2025 from 10.4.0.28
[root@srv ~]# cat rootCA.crt
-----BEGIN CERTIFICATE-----
MIIC+DCCAeCgAwIBAgIUPpJnei28t4YXH8PcmxB+KTUBSIowDQYJKoZIhvcNAQEL
BQAwDTELMAkGA1UEBhMCUlUwHhcNMjUwNjA4MTQzNjMyWhcNMjgwMzI4MTQzNjMy
WjANMQswCQYDVQQGEwJSVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJPt2pewdUiR9aDwfiNWOTA6qRVHck+6oGyYsYzY/6w2KA46c6INfJSZzsu1VUjf
EfxzAlPCQmkh9sRrc10uAj8jU1rFRKAwUzh8vnb5BpTNJM434xzInOri2jQVUG7j
Y/Kvk/w15TxjBM7hQmpjZ15bcEXvbEhJl0FxW+glm9hX4hrMj4jRcNYB9N4tzzYR
IHIX1m2CEuUVVnaWWDwltWIXMjK9lNgN0PlkIpJ/jbdgiD5nj32jYqSs4hN49jZe
4L5kkS1WMdGWr+J5aLghYrpWCVdpChRJlEjDllfJ/hpWyFFz7cK26gSfJreTq2iC
+mVZT9EaG9fDEmCsj6BTD3UCAwEAAaNQME4wHQYDVR0OBBYEFDM2DiABY8x54FWl
0PKBKLmdRwCHMB8GA1UdIwQYMBaAFDM2DiABY8x54FWl0PKBKLmdRwCHMAwGA1Ud
EwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHKfErGh3DUZJpxv4ieb7MIpa3Qo
jmyIYmDlpG3ihEqf4SJd0oggIAnpFLUP0EmDWZXn8uDbRPB51dfOZNQhF1gLEVQ1
9of/Mu6pD3hN+M0XbKcForINaceB99Wr/Rl1ttQUPllDZ2bwgJq06jk3nXS9aiSN
+vQJkPW3+3dfJ0bQyPafIcixgRa0oSxZSK60Ts+5gq4jH/bO2x/E2NgDQub161d8
WYTa6MK1PGB3H7IWzosGEPTepWXNfQd0AqFojPLVNO3Se612xYH/d6VvonE6Tedj
s/BQoOsGF/R3y0NEXZaf04pXIabUnwNbwWn3NMmFkqfQJyVcaCW4vEPl4fU=
-----END CERTIFICATE-----
[root@srv ~]# # COPIED
logout
Connection to 10.9.0.26 closed.
[root@client ~]# cat > rootCA.crt
-----BEGIN CERTIFICATE-----
MIIC+DCCAeCgAwIBAgIUPpJnei28t4YXH8PcmxB+KTUBSIowDQYJKoZIhvcNAQEL
BQAwDTELMAkGA1UEBhMCUlUwHhcNMjUwNjA4MTQzNjMyWhcNMjgwMzI4MTQzNjMy
WjANMQswCQYDVQQGEwJSVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJPt2pewdUiR9aDwfiNWOTA6qRVHck+6oGyYsYzY/6w2KA46c6INfJSZzsu1VUjf
EfxzAlPCQmkh9sRrc10uAj8jU1rFRKAwUzh8vnb5BpTNJM434xzInOri2jQVUG7j
Y/Kvk/w15TxjBM7hQmpjZ15bcEXvbEhJl0FxW+glm9hX4hrMj4jRcNYB9N4tzzYR
IHIX1m2CEuUVVnaWWDwltWIXMjK9lNgN0PlkIpJ/jbdgiD5nj32jYqSs4hN49jZe
4L5kkS1WMdGWr+J5aLghYrpWCVdpChRJlEjDllfJ/hpWyFFz7cK26gSfJreTq2iC
+mVZT9EaG9fDEmCsj6BTD3UCAwEAAaNQME4wHQYDVR0OBBYEFDM2DiABY8x54FWl
0PKBKLmdRwCHMB8GA1UdIwQYMBaAFDM2DiABY8x54FWl0PKBKLmdRwCHMAwGA1Ud
EwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHKfErGh3DUZJpxv4ieb7MIpa3Qo
jmyIYmDlpG3ihEqf4SJd0oggIAnpFLUP0EmDWZXn8uDbRPB51dfOZNQhF1gLEVQ1
9of/Mu6pD3hN+M0XbKcForINaceB99Wr/Rl1ttQUPllDZ2bwgJq06jk3nXS9aiSN
+vQJkPW3+3dfJ0bQyPafIcixgRa0oSxZSK60Ts+5gq4jH/bO2x/E2NgDQub161d8
WYTa6MK1PGB3H7IWzosGEPTepWXNfQd0AqFojPLVNO3Se612xYH/d6VvonE6Tedj
s/BQoOsGF/R3y0NEXZaf04pXIabUnwNbwWn3NMmFkqfQJyVcaCW4vEPl4fU=
-----END CERTIFICATE-----
[root@client ~]# # PASTED
srv
[root@srv ~]# socat OPENSSL-LISTEN:1234,reuseaddr,fork,cert=srv.crt,key=srv.key,verify=0 EXEC:/usr/bin/
cal
client
[root@client ~]# socat openssl:10.9.0.26:1234,cafile=rootCA.crt -
June 2025
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
[root@client ~]#