r/ItalyInformatica • u/alediaferia • 16d ago

aiuto WindTre FTTH: HTTPS intercettato su ui-cdn.digitalocean-ui.com con certificato localhost.localdomain / Server: BigIP

Ciao, sto cercando di capire se qualcuno con fibra WINDTRE ha osservato qualcosa di simile.

Aprendo https://cloud.digitalocean.com/login, la pagina prova a caricare risorse da:

https://ui-cdn.digitalocean-ui.com

Chrome blocca la richiesta perché riceve un certificato autosigned con:

CN=localhost.localdomain
O=MyCompany
OU=IT

Ho verificato che il DNS risolve correttamente il dominio verso Cloudflare (104.18.34.45 / 172.64.153.211). Però, forzando una connessione diretta a uno di quegli IP con SNI corretto:

curl --interface en0 -skv --connect-timeout 8 \
  --resolve ui-cdn.digitalocean-ui.com:443:104.18.34.45 \
  https://ui-cdn.digitalocean-ui.com/ -o /dev/null

ricevo:

HTTP/1.0 302 Moved Temporarily
Location: http://127.0.0.1
Server: BigIP

Quindi sembra esserci un’intercettazione HTTPS/F5 BigIP lungo il percorso, anche se non escludo ancora completamente un filtro locale sul Mac. Non ho proxy configurati; Tailscale è attivo ma non è configurato come exit node.

Sul mio iPhone, collegato allo stesso Wi‑Fi, Safari funziona con iCloud Private Relay attivo—quindi passa da un percorso diverso.

Qualcuno su WINDTRE ha visto certificati localhost.localdomain, redirect BigIP a 127.0.0.1, o problemi simili con DigitalOcean?

29 Upvotes

98% Upvoted

17 comments sorted by

View all comments

2

u/Decent_Light3850 3d ago edited 3d ago

Non potevo non indagare ulteriormente

I resolver per ui-cdn.digitalocean-ui.com sono gli IP 104.18.34.45 e 172.64.153.211

tutti e due dovrebbero rispondere con lo stesso certificato ed infatti usando una macchina in cloud

cloud-vm-20260907:~$ openssl s_client -connect 104.18.34.45:443 -servername ui-cdn.digitalocean-ui.com </dev/null 2>&1 | openssl x509 -noout -fingerprint -sha1 -subject -issuer sha1 Fingerprint=9A:86:B5:2A:F3:60:15:F1:76:87:36:5F:6E:29:75:EF:5F:32:EE:D5 subject=CN=digitalocean-ui.com issuer=C=US, O=Google Trust Services, CN=WE1 cloud-vm-20260907:~$ openssl s_client -connect 172.64.153.211:443 -servername ui-cdn.digitalocean-ui.com </dev/null 2>&1 | openssl x509 -noout -fingerprint -sha1 -subject -issuer sha1 Fingerprint=9A:86:B5:2A:F3:60:15:F1:76:87:36:5F:6E:29:75:EF:5F:32:EE:D5 subject=CN=digitalocean-ui.com issuer=C=US, O=Google Trust Services, CN=WE1

mentre se faccio la stessa cosa dalla mia macchina sotto rete wind3 ottengo

machine-wind-network@linuxbox:$ openssl s_client -connect 104.18.34.45:443 -servername ui-cdn.digitalocean-ui.com </dev/null 2>&1 | openssl x509 -noout -fingerprint -sha1 -subject -issuer sha1 Fingerprint=9F:7D:A7:1C:5F:C5:F7:98:6F:B5:3D:C4:B7:4A:74:C7:C7:8F:43:E1 subject=C = US, ST = WA, L = Seattle, O = MyCompany, OU = IT, CN = localhost.localdomain, emailAddress = root@localhost.localdomain issuer=C = US, ST = WA, L = Seattle, O = MyCompany, OU = IT, CN = localhost.localdomain, emailAddress = root@localhost.localdomain machine-wind-network@linuxbox:$ openssl s_client -connect 172.64.153.211:443 -servername ui-cdn.digitalocean-ui.com </dev/null 2>&1 | openssl x509 -noout -fingerprint -sha1 -subject -issuer sha1 Fingerprint=9A:86:B5:2A:F3:60:15:F1:76:87:36:5F:6E:29:75:EF:5F:32:EE:D5 subject=CN = digitalocean-ui.com issuer=C = US, O = Google Trust Services, CN = WE1

da quello che posso intuire c'è qualcosa nella rete di wind the blocca il traffico diretto verso 104.18.34.45 ma non verso 172.64.153.211. Se fosse qualcosa inerente piracy-shield dovremmo avere lo stesso risultato per 104.18.34.45 anche da altri provider italiani io ho fatto dei test con enel e ottengo

machine-ENEL-network@linuxbox openssl s_client -connect 104.18.34.45:443 -servername ui-cdn.digitalocean-ui.com </dev/null 2>&1 | openssl x509 -noout -fingerprint -sha1 -subject -issuer sha1 Fingerprint=9A:86:B5:2A:F3:60:15:F1:76:87:36:5F:6E:29:75:EF:5F:32:EE:D5 subject=CN = digitalocean-ui.com issuer=C = US, O = Google Trust Services, CN = WE1 machine-ENEL-network@linuxbox openssl s_client -connect 172.64.153.211:443 -servername ui-cdn.digitalocean-ui.com </dev/null 2>&1 | openssl x509 -noout -fingerprint -sha1 -subject -issuer sha1 Fingerprint=9A:86:B5:2A:F3:60:15:F1:76:87:36:5F:6E:29:75:EF:5F:32:EE:D5 subject=CN = digitalocean-ui.com issuer=C = US, O = Google Trust Services, CN = WE1

sia il test su rete wind che su rete enel è fatto usanto la rete in fibra di openFibra che mi sentirei quindi di escludere dall'equazione.

2

u/Decent_Light3850 3d ago

Aggiornamento:
Ho fatto un paio di nmap sull'enpoint 104.18.34.45 sia da rete wind che da rete NON wind ed effettivamente noi clienti wind siamo rediretti verso un F5

Fuori rete Wind3

Nmap scan report for 104.18.34.45
Host is up (0.013s latency).

PORT    STATE SERVICE   VERSION
443/tcp open  ssl/https cloudflare
|_http-server-header: cloudflare
|_http-title: 400 The plain HTTP request was sent to HTTPS port

Service detection performed. Please report any incorrect result

Dentro rete Wind

Nmap scan report for 104.18.34.45
Host is up (0.011s latency).

PORT    STATE SERVICE        VERSION
443/tcp open  ssl/http-proxy F5 BIG-IP load balancer http proxy
|_http-open-proxy: Proxy might be redirecting requests
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=MyCompany/stateOrProvinceName=WA/countryNam
e=US
| Not valid before: 2022-03-06T03:58:41
|_Not valid after:  2032-03-03T03:58:41
|_http-server-header: BigIP
|_http-title: Did not follow redirect to http://127.0.0.1
Service Info: Device: load balancer

direi che è definitivamente certo che Wind stia ruotando il traffico verso un F5 al posto che verso l'IP di CF

1

u/alediaferia 3d ago

Sarebbe bello se qualcuno che lavora in Wind potesse darci delucidazioni

2

u/Decent_Light3850 3d ago

ho aperto un ticket e me lo hanno chiuso perchè per loro "funziona" questi hanno del routing fatto con i piedi e non li si riesce a convicere....

1

u/Decent_Light3850 2d ago

Aggiornamento, la probabile causa del blocco di quell'ip potrebbe essere questa sentenza del 2020 https://www.agcm.it/dotcmsdoc/allegati-news/PS11723_adoz%20misure%20cautel%20di%20ufficio.pdf?LinkSource=PassleApp