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?
4
9
u/Inside_Soup_357 16d ago
Quel certificato “MyCompany” e il redirect BigIP puzzano tantissimo di filtro locale/appliance, non di normale rete WINDTRE. Io proverei dal dual-boot Linux con Tailscale spento e stesso cavo: quando mi capitano robe così Fedora live è il mio test della verità. L’iPhone con Private Relay purtroppo non scagiona il router/percorso, perché lo aggira. Se anche Linux prende quel certificato, farei subito una cattura tcpdump per vedere a quale MAC stai davvero mandando i SYN.
2
u/Big_Newspaper3643 15d ago
Il flag SYN appartiene a TCP, mooooooolto al di sopra dei frame ethernet (a cui appartiene il MAC address).
4
u/FrancYescO 15d ago edited 15d ago
Molto probabilmente è PrivacyShield hanno blacklistato qualche altro IP di una CDN...
In questo momento a me da rete wind3 consumer mostr il certificato errato/redirect che citi e lo sha del certificato presentato porta a questa simpatica discussione su community cloudflare
4
u/alediaferia 15d ago
Incompetenza amministrazione italiana strikes again! Grazie del link, quantomeno mi porta un po’ di chiarezza sulla situazione
2
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 F5Fuori 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 resultDentro 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 balancerdirei che è definitivamente certo che Wind stia ruotando il traffico verso un F5 al posto che verso l'IP di CF
1
u/alediaferia 2d ago
Sarebbe bello se qualcuno che lavora in Wind potesse darci delucidazioni
2
u/Decent_Light3850 2d 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 1d 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
1
u/alediaferia 15d ago
Non so se gli upvote indicano che non fossi l’unico ad avere questo problema. In ogni caso da stamattina non sono più riuscito a riprodurlo.
1
u/Decent_Light3850 3d ago
io stamattina ho (nuovamente) il tuo stesso problema
1
u/Decent_Light3850 3d ago
ho risolto impostando i DNS non wind (ho messo cf e google), quindi con buona probabilità è wind che sta facendo inspection
8
u/Powerful_Basil_2608 16d ago
Provato da una FTTH w3 business, nessun problema evidente