Проверка обхода ssl сертификата в подрывной деятельности

Ответ 1

Я думаю, у вас есть два варианта; бросая все предостережения за борт и устанавливая trust-server-cert и не интерактивные из командной строки:

 svn help co
 .... snip....
--non-interactive        : do no interactive prompting
--trust-server-cert      : accept unknown SSL server certificates without
                         prompting (but only with '--non-interactive')

а другой вариант - использовать что-то вроде openssl s_client с -showcerts, чтобы проверить и проверить, изменился ли сертификат до вызова svn, - и затем либо прекратите очень чисто, и позвольте человеку сделать решение или что-то грязное - подобно использованию -showcert для обновления известного сертификата в ~/.subversion.

В любом случае - бит неинтуитивной магии находится в файлах в ~/.subversion/auth/svn.ssl.server/ <serverrecord > - для получения необходимой информации о сертификате:

cat <serverrecord> | grep ^MII | base64decode  | openssl x509 -text -inform DER

или что-то вроде

cat <serverrecord> | grep ^MII | base64decode  | openssl x509 -text -inform DER -noout - out current-cert.pem

и затем может использовать openssl s_client с ключом -CApath или проверить с этим сертификатом, чтобы увидеть, изменилось ли оно и/или использовать -showcert для перекрестной проверки. (Примечание: заменить perl -e 'использовать MIME:: Base64; print decode_base64 (join ("",));' для base64decode, если необходимо).

Ответ 2

Другой вариант - использовать expect. Используя ожидание, вы можете имитировать пользователя, принимающего сертификат. Он будет работать, когда другие варианты не будут. Я создал это, чтобы загрузить код из svn в файл Docker.

#!/usr/bin/expect -f

set svn_username [lindex $argv 0]
set svn_password [lindex $argv 1]
set svn_url [lindex $argv 2]

spawn svn --username=${svn_username} --password=${svn_password} list ${svn_url}
expect "(R)eject, accept (t)emporarily or accept (p)ermanently? "
send -- "p\r"
expect "Store password unencrypted (yes/no)? "
send "no\r"
expect -re "[email protected]*:\/#"

Ответ 3

Существует два возможных сценария: сертификат ненадежен, но действителен (например, действительный самозаверяющий сертификат, например) или сертификат недействителен (например, когда вы получаете доступ к машине в вашей локальной сети по IP или вне вашей локальной сети по FQDN, и этот компьютер имеет сертификат, выданный его символическому имени). Клиент svn не будет доверять сертификату второго типа, даже если используется опция --trust-server-certificate. Во втором сценарии я могу только подумать о том, чтобы использовать запись файла хоста для псевдонима, что IP-адрес устройства для его внутреннего имени.

Иллюстрация сценария 2, с которым я когда-то сталкивался, когда VisualSVN был установлен со всеми параметрами по умолчанию и сгенерировал сертификат для символического имени машины, которое он обнаружил:

Имя LAN-машины MACHINE1 запускает сервер SVN, и у него установлен сертификат, который был выдан MACHINE1. Вы пытаетесь получить доступ к SVN через свой IP-адрес и получить недопустимую ошибку сертификата.

Вы также получите эту ошибку, если этот MACHINE1 доступен из-за пределов вашей локальной сети с помощью FQDN, например svn.domain.com, и вы подключаетесь к FQDN.

В обоих случаях svn выдаст неверную ошибку сертификата.

Вы можете добавить запись в файл hosts для сопоставления IP-адреса устройства (локальной или внешней в зависимости от того, откуда вы его обращаетесь), в сертификат имени, который был отправлен:

123.45.67.89 MACHINE1

и получить доступ к SVN через https://machine1/svn/, чтобы обойти эту ситуацию.