Mailing List Archive: Interesting Ali Express web server behavior...

Interesting Ali Express web server behavior...

Dec 9, 2023, 9:55 PM

Post #1 of 14 (291 views)

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

Re: Interesting Ali Express web server behavior... [ In reply to ]

bortzmeyer at nic

Dec 9, 2023, 11:15 PM

Post #2 of 14 (291 views)

Permalink

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/.

Re: Interesting Ali Express web server behavior... [ In reply to ]

sabri at cluecentral

Dec 9, 2023, 11:45 PM

Post #3 of 14 (291 views)

Permalink

----- 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

Re: Interesting Ali Express web server behavior... [ In reply to ]

mike.lyon at gmail

Dec 9, 2023, 11:51 PM

Post #4 of 14 (291 views)

Permalink

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/.

Re: Interesting Ali Express web server behavior... [ In reply to ]

chris at thesysadmin

Dec 10, 2023, 12:08 AM

Post #5 of 14 (291 views)

Permalink

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
>

Re: Interesting Ali Express web server behavior... [ In reply to ]

nanog at nanog

Dec 10, 2023, 1:40 AM

Post #6 of 14 (289 views)

Permalink

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

Re: Interesting Ali Express web server behavior... [ In reply to ]

bill at herrin

Dec 10, 2023, 2:42 AM

Post #7 of 14 (289 views)

Permalink

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/

Re: Interesting Ali Express web server behavior... [ In reply to ]

jlewis at lewis

Dec 10, 2023, 2:17 PM

Post #8 of 14 (289 views)

Permalink

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.

Re: Interesting Ali Express web server behavior... [ In reply to ]

beecher at beecher

Dec 10, 2023, 6:53 PM

Post #9 of 14 (289 views)

Permalink

>
> 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
>
>

Re: Interesting Ali Express web server behavior... [ In reply to ]

nanog at nanog

Dec 10, 2023, 11:28 PM

Post #10 of 14 (288 views)

Permalink

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/.

Re: Interesting Ali Express web server behavior... [ In reply to ]

nanog at nanog

Dec 10, 2023, 11:29 PM

Post #11 of 14 (288 views)

Permalink

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

Re: Interesting Ali Express web server behavior... [ In reply to ]

sabri at cluecentral

Dec 11, 2023, 9:55 AM

Post #12 of 14 (284 views)

Permalink

----- 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

Re: Interesting Ali Express web server behavior... [ In reply to ]

nanog at nanog

Dec 11, 2023, 9:57 AM

Post #13 of 14 (284 views)

Permalink

> 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.

In my experience, back then, most DCs ran out of cooling well before they ran out of power.

YMMV

Owen

Re: Interesting Ali Express web server behavior... [ In reply to ]

ltd at interlink

Dec 11, 2023, 7:40 PM

Post #14 of 14 (274 views)

Permalink

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.