> > But why would AliExpress be redirecting to DDN space? Is this legitimate? > Ali hoping to get away with squatting, or something else?
I've seen a large number of cases that a company was using someone else's non-RFC1918 space for some reason, and that was accidentally exposed via application communication when some process / procedure they were using to fix that up didn't work. This feels like that to me. On Sun, Dec 10, 2023 at 12:57 AM Owen DeLong via NANOG <nanog@nanog.org> wrote: > So I’m having trouble connecting to the Ali Express web server this > evening and decided to investigate a little. > > What I found surprised me… > > owen@odmbpro3-3 ~ % openssl s_client -connect www.aliexpress.com:443 > > CONNECTED(00000005) > > depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert > Global Root CA > > verify return:1 > > depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1 > > verify return:1 > > depth=0 C = CN, ST = \E6\B5\99\E6\B1\9F\E7\9C\81, L = > \E6\9D\AD\E5\B7\9E\E5\B8\82, O = Alibaba Cloud Computing Ltd., CN = > ae01.alicdn.com > > verify return:1 > … certificate stuff, blah blah from Akamai, routine… > > SSL-Session: > > Protocol : TLSv1.3 > > Cipher : AEAD-CHACHA20-POLY1305-SHA256 > > Session-ID: > > Session-ID-ctx: > > Master-Key: > > Start Time: 1702187128 > > Timeout : 7200 (sec) > > Verify return code: 0 (ok) > > --- > > read R BLOCK > > read R BLOCK > > GET / HTTP/1.1 > > Host: www.aliexpress.com > > > HTTP/1.1 302 Moved Temporarily > > Content-Type: text/html > > Content-Length: 258 > > Location: http://33.3.37.57/ > > Access-Control-Allow-Origin: https://hz.aliexpress.com > > Server: Tengine/Aserver > > EagleEye-TraceId: 2103253917021871367418570ec8e3 > > Strict-Transport-Security: max-age=31536000 > > Timing-Allow-Origin: * > > Date: Sun, 10 Dec 2023 05:45:36 GMT > > Connection: keep-alive > > Set-Cookie: ali_apache_id=33.3.37.57.1702187136742.612980.2; path=/; > domain=.aliexpress.com; expires=Wed, 30-Nov-2084 01:01:01 GMT > > Server-Timing: cdn-cache; desc=MISS > > Server-Timing: edge; dur=65 > > Server-Timing: origin; dur=3 > > Server-Timing: ak_p; > desc="1702187128314_400069768_2521981097_6837_5323_25_43_-";dur=1 > > > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > > <html> > > <head><title>302 Found</title></head> > > <body bgcolor="white"> > > <h1>302 Found</h1> > > <p>The requested resource resides temporarily under a different URI.</p> > > <hr/>Powered by Tengine</body> > > </html> > … OK, so far so good, though the hard coded IP redirect is a bit odd. > Especially when you consider this: > > NetRange: 33.0.0.0 - 33.255.255.255 > > CIDR: 33.0.0.0/8 > > NetName: DISN-IP-LEGACY > > NetHandle: NET-33-0-0-0-1 > > Parent: () > > NetType: Direct Allocation > > OriginAS: > > Organization: DoD Network Information Center (DNIC) > > RegDate: 1991-01-01 > > Updated: 2013-09-11 > > Ref: https://rdap.arin.net/registry/ip/33.0.0.0 > > > > OrgName: DoD Network Information Center > > OrgId: DNIC > > Address: 3990 E. Broad Street > > City: Columbus > > StateProv: OH > > PostalCode: 43218 > > Country: US > > RegDate: > > Updated: 2011-08-17 > > Ref: https://rdap.arin.net/registry/entity/DNIC > > > > OrgTechHandle: REGIS10-ARIN > > OrgTechName: Registration > > OrgTechPhone: +1-844-347-2457 > > OrgTechEmail: disa.columbus.ns.mbx.arin-registrati...@mail.mil > > OrgTechRef: https://rdap.arin.net/registry/entity/REGIS10-ARIN > > > OrgAbuseHandle: REGIS10-ARIN > > OrgAbuseName: Registration > > OrgAbusePhone: +1-844-347-2457 > > OrgAbuseEmail: disa.columbus.ns.mbx.arin-registrati...@mail.mil > > OrgAbuseRef: https://rdap.arin.net/registry/entity/REGIS10-ARIN > > > OrgTechHandle: MIL-HSTMST-ARIN > > OrgTechName: Network DoD > > OrgTechPhone: +1-844-347-2457 > > OrgTechEmail: disa.columbus.ns.mbx.hostmaster-dod-...@mail.mil > > OrgTechRef: https://rdap.arin.net/registry/entity/MIL-HSTMST-ARIN > > Which seems in line with the announcement of that address I’m seeing: > > owen@delong-fmt2-mx-01> show route 33.3.37.57 > > > inet.0: 947480 destinations, 2018685 routes (947480 active, 0 holddown, 0 > hidden) > > + = Active Route, - = Last Active, * = Both > > > 33.0.0.0/8 *[BGP/170] 1w6d 05:39:58, localpref 2000 > > AS path: 6939 3356 749 I, validation-state: > unverified > > > to 64.71.131.26 via ge-2/0/0.0 > > [BGP/170] 1w6d 05:35:29, localpref 100, from > 192.124.40.252 > > AS path: 36236 2914 3356 749 I, validation-state: > unverified > > > via gr-2/3/0.70 > > (AS749 is also DISA/DDI) > > But why would AliExpress be redirecting to DDN space? Is this legitimate? > Ali hoping to get away with squatting, or something else? > > Owen > >
