Jak sprawdzić, czy DDCLIENT używa protokołu SSL, a jeśli nie, to jak go wymusić?

Postępowałem zgodnie z tym przewodnikiem na temat konfigurowania VPN na mojej pi. Część kroków polega na skonfigurowaniu i skonfigurowaniu dynamicznej usługi dns. Utworzyłem kilka kont na wielu platformach. Nie ma nazwy IP i dynamicdns. Poniżej znajduje się wyjście mojego pliku ddclient.conf, który łączy się dobrze na obu dynamicznych stronach dns.

daemon=60                               # check every 60 seconds
syslog=yes                              # log update msgs to syslog
mail=root                               # mail all msgs to root
mail-failure=root                       # mail failed update msgs to root
pid=/var/run/ddclient.pid               # record PID in file.
ssl=yes                                 # use ssl-support.  Works with
                                        # ssl-library
use=web, web=myip.dnsdynamic.com        # get ip from server.
server=www.dnsdynamic.org               # default server
login=YOURUSERNAME                      # default login
password=YOURPASSWORD                       # default password
server=www.dnsdynamic.org,              \
protocol=dyndns2                        \
MYDOMAIN.dnsdynamic.COM

Mój problem polega na tym , że w tym artykule pokazano, jak sprawdzić, czy twoja pi łączy się przez SSL. Kiedy biegnę

sudo ddclient -verbose -debug -noquiet -query 

pokazuje połączenie przez HTTP vs HTTPS lub SSL dla każdej witryny. Sprawdziłem, że ssl został zainstalowany przez uruchomienie

sudo apt-get install ssh libio-socket-ssl-perl

Jakieś pomysły na to, czy łączy się przez ssl lub jak mogę to zmusić? Przejrzałem też ten artykuł. Widziałem, że ddclient stwierdził, że użyje protokołu SSL, jeśli jest dostępny, zastanawiam się, czy jest to ograniczenie do korzystania z bezpłatnej witryny DynamicDns, czy też coś przeoczam. Artykuły sprawiły, że wyglądało to tak, jakby strony, z których korzystam, nie używały protokołu SSL i dnsdynamic.

Znalazłem odpowiedź i czuję się bardzo głupio, nie zastanawiając się wcześniej.

daemon=60                               # check every 60 seconds
syslog=yes                              # log update msgs to syslog
mail=root                               # mail all msgs to root
mail-failure=root                       # mail failed update msgs to root
pid=/var/run/ddclient.pid               # record PID in file.
ssl=yes                                 # use ssl-support.  Works with
                                        # ssl-library
use=web, web=https://myip.dnsdynamic.org        # get ip from server.
server=www.dnsdynamic.org               # default server
login=USERNAME                          # default login
password=PASSWORD                       # default password
server=www.dnsdynamic.org,              \
protocol=dyndns2                        \
YOUR DOMAIN GOES HERE

Powyższe wymusi SSL i połączy się przez SSL. Wprowadziłem dwie zmiany.

Linia use=web, web=myip.dnsdynamic.compowinna być use=web, web=https://myip.dnsdynamic.org. Zmiana z .comna .orgprzerywa awarie połączenia. Dodanie https://przed ciągiem połączenia umożliwia połączenie przez SSL.

Dane wyjściowe z use=web, web=myip.dnsdynamic.orgprogramów:

use=web, web=loopia address is IPADDRESSISHERE
CONNECT:  myip.dnsdynamic.org
CONNECTED:  using HTTP
SENDING:  GET / HTTP/1.0
SENDING:   Host: myip.dnsdynamic.org
SENDING:   User-Agent: ddclient/3.8.2
SENDING:   Connection: close

Dane wyjściowe z use=web, web=https://myip.dnsdynamic.orgprogramów:

use=web, web=loopia address is IPADDRESSISHERE
CONNECT:  myip.dnsdynamic.org

The verification of cert '/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA/CN=www.dnsdynamic.org'
failed against the host 'myip.dnsdynamic.org' with the default verification scheme.

   THIS MIGHT BE A MAN-IN-THE-MIDDLE ATTACK !!!!

To stop this warning you might need to set SSL_verifycn_name to
the name of the host you expect in the certificate.

CONNECTED:  using SSL
SENDING:  GET / HTTP/1.0
SENDING:   Host: myip.dnsdynamic.org
SENDING:   User-Agent: ddclient/3.8.2
SENDING:   Connection: close

Nadal nie jestem pewien, dlaczego wymuszanie ssl=yesnie powoduje automatycznego użycia HTTPS, ale teraz łączy się ono za pośrednictwem protokołu SSL, a polecenie widoczne w @George pomaga mi zweryfikować:sudo ddclient -verbose -debug -noquiet -query

To tylko część „get IP”. Rzeczywista aktualizacja dynamicznego serwera DNS nie jest wyświetlana w wynikach. Nadal można to zrobić przez HTTP.

root@ad26e03e9704:/bin# ddclient -daemon=0 -noquiet -debug -file /config/ddclient.conf
DEBUG:    get_ip: using cmd, /config/get_ip.sh reports 10.0.0.1
DEBUG:
DEBUG:     nic_dyndns2_update -------------------
DEBUG:    proxy  =
DEBUG:    url    = http://dyndns.strato.com/nic/update?system=dyndns&hostname=bla.mydomain.com&myip=10.0.0.1
DEBUG:    server = dyndns.strato.com
SUCCESS:  updating bla.mydomain.com: good: IP address set to 10.0.0.1

Jeśli umieszczę https przed serwerem, otrzymam:

DEBUG:    url    = http://https://dyndns.strato.com/nic/update?system=dyndns&hostname=bla.mydomain.com&myip=10.0.0.1

Ponieważ byłem również zdezorientowany faktem, że adres URL w linii wyjściowej

DEBUG:    url    = http://(...)

zaczyna się od HTTP zamiast HTTPS, chociaż mam ssl=yesw swojej konfiguracji, postanowiłem zajrzeć do kodu źródłowego, aby zobaczyć, co się dzieje. Okazuje się, że w funkcji, w geturlktórej inicjowane jest połączenie z serwerem, http://część jest i tak usuwana z adresu URL, aby nie wskazywała na faktyczny typ połączenia. Jeśli chcesz się upewnić, że ddclient używa SSL, po prostu wywołaj ddclient z terminala jako

sudo ddclient -verbose -force

i poszukaj linii

CONNECTED:  using HTTP

lub

CONNECTED:  using SSL

W tym drugim przypadku ddclient naprawdę używa SSL i możesz zacząć. Zauważ, że to ssl=yesustawienie nie dotyczy początkowego wyszukiwania adresu IP, którego używa ddclient do sprawdzenia, czy twój publiczny adres IP się zmienił (ten, który jest skonfigurowany przez use=...), więc dla pierwszego połączenia nadal widziszCONNECTED: using HTTPjak wspomniano w @Shaulinator, chyba że jawnie ustawisz adres HTTPS. Nie powinno to jednak stanowić problemu z bezpieczeństwem, ponieważ adres IP zwrócony przez to żądanie jest prawdopodobnie używany tylko w celu uniknięcia niepotrzebnego wysiłku po stronie serwera; nie jest wysyłany do serwera w rzeczywistym żądaniu aktualizacji, ponieważ serwer w prosty sposób zna twój adres IP, gdy ddclient inicjuje połączenie SSL. Sprawdziłem to tylko wyraźnie dla protokołu Freedns, ale byłbym zaskoczony, gdyby był inny dla innych protokołów.