Interesting Ali Express web server behavior...
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-registrations@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-registrations@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-nic@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
On Sat, Dec 09, 2023 at 09:55:31PM -0800, Owen DeLong via NANOG <nanog@nanog.org> wrote a message of 1136 lines which said:
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
No idea. The IP address does not reply to HTTP requests, anyway. A practical joke? Note that this redirection takes places only when there is no User-Agent field. If you say 'User-Agent: Mozilla', you get a proper redirection, in my case to https://fr.aliexpress.com/.
I notice a weird issue like this with Alibaba when i try to use my Comcast connection. Turn my wifi off and now it works flawlessly. Are you using your comcast connection? -Mike
On Dec 9, 2023, at 21:17, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Sat, Dec 09, 2023 at 09:55:31PM -0800, Owen DeLong via NANOG <nanog@nanog.org> wrote a message of 1136 lines which said:
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
No idea. The IP address does not reply to HTTP requests, anyway. A practical joke?
Note that this redirection takes places only when there is no User-Agent field. If you say 'User-Agent: Mozilla', you get a proper redirection, in my case to https://fr.aliexpress.com/.
No, in this case, I was using HE uplink from the Cabinet in FMT2 for testing using my AS1734 space 192.159.10.0/24 as source address. Owen
On Dec 9, 2023, at 23:51, Mike Lyon <mike.lyon@gmail.com> wrote:
I notice a weird issue like this with Alibaba when i try to use my Comcast connection. Turn my wifi off and now it works flawlessly.
Are you using your comcast connection?
-Mike
On Dec 9, 2023, at 21:17, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Sat, Dec 09, 2023 at 09:55:31PM -0800, Owen DeLong via NANOG <nanog@nanog.org> wrote a message of 1136 lines which said:
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
No idea. The IP address does not reply to HTTP requests, anyway. A practical joke?
Note that this redirection takes places only when there is no User-Agent field. If you say 'User-Agent: Mozilla', you get a proper redirection, in my case to https://fr.aliexpress.com/.
Sent from my iPhone
On Dec 10, 2023, at 2:17 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Sat, Dec 09, 2023 at 09:55:31PM -0800, Owen DeLong via NANOG <nanog@nanog.org> wrote a message of 1136 lines which said:
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
No idea. The IP address does not reply to HTTP requests, anyway. A practical joke?
Note that this redirection takes places only when there is no User-Agent field. If you say 'User-Agent: Mozilla', you get a proper redirection, in my case to https://fr.aliexpress.com/.
My guess would be they’re doing this to redirect unwanted / non-legitimate traffic away.
----- On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org wrote: Hi,
Location: http://33.3.37.57/
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
Not very long ago I worked for a well-known e-commerce platform where we nearly ran out of RFC1918 space. We seriously considered using what was then un-advertised DOD space to supplement RFC1918 space inside our data centers. Perhaps AliExpress did get to that level of desperateness? Thanks, Sabri
Starting to digress here for a minute... How big would a network need to get, in order to come close to exhausing RFC1918 address space? There are a total of 17,891,328 IP addresses between the 10/8 prefix, 172.16/12 space and 192.168/16 space. If one was to allocate 10 addresses to each host, that means it would require 1,789,132 hosts to exhaust the space. - Christopher H. On Sun, 10 Dec 2023 at 18:45, Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org wrote:
Hi,
Location: http://33.3.37.57/
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
Not very long ago I worked for a well-known e-commerce platform where we nearly ran out of RFC1918 space. We seriously considered using what was then un-advertised DOD space to supplement RFC1918 space inside our data centers.
Perhaps AliExpress did get to that level of desperateness?
Thanks,
Sabri
How big would a network need to get, in order to come close to exhausing RFC1918 address space? […] If one was to allocate 10 addresses to each host, that means it would require 1,789,132 hosts to exhaust the space. Total availability is not usually the problem - poor allocation of space done in the 80s is. I’ve worked with a telco a while ago which had ‘run out of 10/8’ by having allocated multiple /16s to their largest sites for lan/mgmt/control. The plan to ‘free up IP space’ included resetting practically every 20 years old air conditioner they had in the country and put them in a different subnet, same for fire and access control systems (air conditioners and fire control specifically didn’t support IP address change, you had to drop the entire config). If you think about the scale of the operation then suddenly 33/8 becomes very, very appealing. - Christopher H. On Sun, 10 Dec 2023 at 18:45, Sabri Berisha <sabri@cluecentral.net <mailto:sabri@cluecentral.net> > wrote: ----- On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org <mailto:nanog@nanog.org> wrote: Hi,
Location: http://33.3.37.57/ <http://33.3.37.57/>
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
Not very long ago I worked for a well-known e-commerce platform where we nearly ran out of RFC1918 space. We seriously considered using what was then un-advertised DOD space to supplement RFC1918 space inside our data centers. Perhaps AliExpress did get to that level of desperateness? Thanks, Sabri
On Sun, Dec 10, 2023 at 12:08 AM Christopher Hawker <chris@thesysadmin.au> wrote:
How big would a network need to get, in order to come close to exhausing RFC1918 address space?
AWS. They exhausted it, broke up the regions reusing the address space, then exhausted it again. Exhaustion was one of the motivations for Facebook going IPv6-only internally. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Given micro services and VM architectures these days, it’s not even difficult to imagine a company as large as Ali Baba burning through more than 17 milllion hosts. Owen
On Dec 10, 2023, at 00:08, Christopher Hawker <chris@thesysadmin.au> wrote:
Starting to digress here for a minute...
How big would a network need to get, in order to come close to exhausing RFC1918 address space? There are a total of 17,891,328 IP addresses between the 10/8 prefix, 172.16/12 space and 192.168/16 space. If one was to allocate 10 addresses to each host, that means it would require 1,789,132 hosts to exhaust the space.
- Christopher H.
On Sun, 10 Dec 2023 at 18:45, Sabri Berisha <sabri@cluecentral.net <mailto:sabri@cluecentral.net>> wrote:
----- On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org <mailto:nanog@nanog.org> wrote:
Hi,
Location: http://33.3.37.57/
But why would AliExpress be redirecting to DDN space? Is this legitimate? Ali hoping to get away with squatting, or something else?
Not very long ago I worked for a well-known e-commerce platform where we nearly ran out of RFC1918 space. We seriously considered using what was then un-advertised DOD space to supplement RFC1918 space inside our data centers.
Perhaps AliExpress did get to that level of desperateness?
Thanks,
Sabri
----- On Dec 10, 2023, at 12:08 AM, Christopher Hawker chris@thesysadmin.au wrote: Hi,
Starting to digress here for a minute... How big would a network need to get, in order to come close to exhausing RFC1918 address space? There are a total of 17,891,328 IP addresses between the 10/8 prefix, 172.16/12 space and 192.168/16 space. If one was to allocate 10 addresses to each host, that means it would require 1,789,132 hosts to exhaust the space.
Imagine a 20 year old platform originally built in the late 90s/early 2000s, gradually evolving to what it is today. You'll have several version of design, several versions of applications, several versions of networking, firewalls, and other infrastructure. It is so old, when it was first built, each HTTPS address required its own IP. What you end up with is your typical pod design with 40-some TORs where you allocate a /24 per IRB, not knowing how many hosts are going to end up on the hypervisor. And due to PCI-DSS restrictions, you may need multiple IRBs per TOR. And all of this in an environment where datacenters and pods are scaled based on the amount of power available, not the amount of space. Now factor in "legacy" pods and datacenters that were never properly migrated out of, an address-guzzling corporate network administered by a separate team that for some reason also needs to talk to prod and thus demands unique RFC1918 space out of the same pool, and all of a sudden that DOD space looks awfully appealing. This is how you end up with projects named "Save The Bacon". Even after very rigorous reclaiming we still ended up using close to 60% of RFC1918 space. Thanks, Sabri
On Sun, Dec 10, 2023 at 7:09 PM Christopher Hawker <chris@thesysadmin.au> wrote:
How big would a network need to get, in order to come close to exhausing RFC1918 address space? There are a total of 17,891,328 IP addresses between the 10/8 prefix, 172.16/12 space and 192.168/16 space. If one was to allocate 10 addresses to each host, that means it would require 1,789,132 hosts to exhaust the space.
See 30 minute mark of https://youtu.be/ARlBHmPy7Zc?t=1787. We talked about this in a NANOG88 presentation too but had a bigger timeslot to talk at AusNOG so we said a bit more about it.
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-registrations@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-registrations@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-nic@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
participants (11)
-
Christopher Hawker -
Giorgio Bonfiglio -
Jon Lewis -
Lincoln Dale -
Mike Lyon -
Owen DeLong -
owen＠Delong.com
-
Sabri Berisha -
Stephane Bortzmeyer -
Tom Beecher -
William Herrin