TLS Landscape Report for X/Twitter

Scope

This report covers the public TLS posture observed across the X and Twitter domain set, including the base domains x.com and twitter.com, plus related hostnames present in certificate SANs and observed endpoints.

In-scope bases (from provided set):

• x.com
• twitter.com

Scale (Issuer & Validity included)

Observed footprint indicates a large, actively managed certificate ecosystem with substantial SAN reuse/duplication.

High-level counts

• Hostnames: 849
• Certificates: 3,664
• SAN entries (total): 14,581
• Distinct SAN names: 1,012
• Duplicate SAN instances: 13,569 (suggesting repeated inclusion of the same names across many certs)

Top issuers & validity profiles (by certificate count)

Table limited to 10 rows.

Issuer	Typical validity (days)	Certificates
Let’s Encrypt	90	3,227
Amazon	395	209
Google Trust Services	90	134
DigiCert Inc	365	40
DigiCert Inc	397	16
Amazon	396	8
Sectigo Limited	91	1
DigiCert Inc	378	1
Certainly	30	1

Key algorithm mix (certificates)

• RSA: 3,317
• ECDSA: 320
• Unknown: 27

Interpretation: RSA dominates issuance volume, with a smaller but meaningful ECDSA presence. The “Unknown” segment is small but worth periodically re-validating to ensure it’s not masking atypical chains or parsing gaps.

Certificate Churn

Churn signals are visible via distinct certificate counts per SAN name, where certain names appear across unusually high numbers of distinct certificates.

Notable SAN names by distinct certificates (sample)

Table limited to 10 rows.

SAN name	Distinct certificates
ipmi.wilson.local.twitter.com	181
x.com	142
api.wilson.local.twitter.com	140
stats.wilson.local.twitter.com	140
*.x.com	135
twitter.com	135
*.twitter.com	127
api.tweetdeck.com	125
web.tweetdeck.com	125
blog.tweetdeck.com	125

Observations:

• The presence of .local.twitter.com labels in public SAN data is unusual. It may reflect internal naming that is nevertheless externally visible through certificate transparency or public endpoints, and it tends to correlate with high churn.
• Heavy reliance on 90-day certs (Let’s Encrypt, Google Trust Services) naturally increases rotation frequency; however, the outliers above still merit review to confirm automation and inventory hygiene.

Subdomain Structure

Hostname depth distribution suggests a heavy concentration in deeper (4–5 label) names.

Hostname depth (label counts)

• 2 labels: 2 occurrences
• 3 labels: 68 occurrences
• 4 labels: 555 occurrences
• 5 labels: 212 occurrences
• 6 labels: 12 occurrences

Most common subdomains

Counts represent distinct hostnames within each level-3 bucket, and include all hostnames matching *.bucket and deeper (e.g., a.b.atla.twitter.com, x.y.z.atla.twitter.com count toward atla.twitter.com).

Table limited to 10 rows total (top buckets across both bases).

Level-3 bucket	Distinct hostnames
atla.twitter.com	79
local.twitter.com	73
pdxa.twitter.com	60
money-dev.x.com	56
vault.x.com	38
money-staging.x.com	38
money.x.com	38
qus1.twitter.com	22
payments-dev.x.com	29
memy.twitter.com	19

Notes:

• money* and payments* buckets under x.com read like development/staging/payment-adjacent surfaces, which tend to be the first places where legacy compatibility (or policy drift) shows up.
• local.twitter.com is a particularly conspicuous bucket name for externally observable TLS artifacts.

TLS Versions

The observed version support indicates modern defaults (TLS 1.2/1.3) with a smaller legacy tail still allowing TLS 1.0/1.1.

TLS Version	Hostnames	IPs
TLS 1.0	14	14
TLS 1.1	14	14
TLS 1.2	76	103
TLS 1.3	76	103

Interpretation:

• The identical 1.2/1.3 counts suggest most modern endpoints negotiate both.
• A non-trivial but bounded segment (14 hostnames) still supports TLS 1.0 and 1.1.

Legacy TLS

Legacy protocol support was observed on 14 distinct hostnames for TLS 1.0 and TLS 1.1.

Legacy TLS counts

• TLS 1.0: 14 hostnames
• TLS 1.1: 14 hostnames

Sample hostnames offering legacy TLS (TLS 1.0/1.1)

• admin.money-dev-onprem.x.com
• data.money-dev-onprem.x.com
• envoy-standalone.money-dev-onprem.x.com
• internal-orchestrator-grpc.money-dev-onprem.x.com
• karma.money-dev-onprem.x.com
• money-dev-onprem.x.com
• o.money-dev-onprem.x.com
• payments-web-agent-tools.money-dev-onprem.x.com
• payments-web-documents.money-dev-onprem.x.com
• payments-web.money-dev-onprem.x.com
• realm-cloud1.x.com
• web-api.money-dev-onprem.x.com
• webhooks.money-dev-onprem.x.com
• www.realm-cloud1.x.com

Risk context:

• Enabling TLS 1.0/1.1 increases exposure to downgrade/weak-cipher negotiation risks and may violate modern compliance baselines. Even if these are “dev” or “onprem” labeled, they are still observable surfaces and should be treated as internet-facing until proven otherwise.

Expired Certificates Still Served

• Count: 0
• Samples: None

Revoked Certificates Still Served

• Count: 0
• Samples: None

Cipher Exposure

Weak cipher exposure is limited but present. Ordering below is from weakest to stronger, prioritizing 3DES, then RSA key exchange, then CBC+SHA1 suites. Even when weak suites are rare, their presence can enable downgrade paths or reduce confidentiality for misconfigured clients.

Weak ciphers observed (all listed)

1. TLS_RSA_WITH_3DES_EDE_CBC_SHA

   • Occurrences: 10
   • Distinct hostnames: 2
     Why it matters: 3DES is deprecated (SWEET32 class issues) and RSA key exchange lacks forward secrecy; combined, this is among the weakest commonly recognizable configurations still seen on the internet.

2. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

   • Occurrences: 54
   • Distinct hostnames: 18
     Why it matters: CBC with SHA-1 is legacy-grade. While ECDHE provides forward secrecy, CBC/SHA1 suites are generally discouraged and can reflect conservative compatibility policies.

3. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

   • Occurrences: 54
   • Distinct hostnames: 18
     Why it matters: Similar to the above; stronger AES size does not remove the CBC/SHA1 legacy concerns.

Interpretation:

• The 3DES+RSA suite is the primary red flag—even at low frequency—because it represents a configuration that should typically be fully removed rather than merely deprioritized.
• The CBC+SHA1 suites may exist for older client compatibility. That can be a deliberate policy choice, but the security tradeoff remains: if a legacy client can negotiate it, an attacker may attempt to push handshakes toward weaker options under certain downgrade/misconfiguration conditions.

PQC Readiness

PQC readiness appears mixed across observed endpoints.

• PQC-ready: 54 distinct hostnames (154 occurrences)
• Not PQC-ready: 22 distinct hostnames (46 occurrences)

Notes:

• “PQC-ready” typically indicates support for post-quantum/hybrid key establishment in TLS 1.3 stacks (implementation-dependent). The split suggests partial rollout—often concentrated on newer edges/CDNs first, with internal, staging, or specialty stacks lagging.
• Given the strong presence of modern TLS (1.3 widely supported), expanding PQC capability may be operationally straightforward once standardized profiles and monitoring are in place.

Key Findings

1. Modern TLS is the norm, but legacy protocol support persists.
   TLS 1.2/1.3 coverage is strong, yet 14 hostnames still offer TLS 1.0/1.1, largely clustered in money-dev-onprem.x.com and related surfaces.

2. A small but meaningful weak-cipher tail remains—most notably 3DES with RSA key exchange.
   TLS_RSA_WITH_3DES_EDE_CBC_SHA was observed (10 occurrences, 2 hostnames). This is typically a “remove entirely” class of suite in modern baselines.

3. CBC+SHA1 cipher suites are present across multiple hostnames.
   Two ECDHE_ECDSA CBC/SHA1 suites appear across 18 hostnames. This may reflect compatibility policy, but it still increases exposure to legacy cryptographic constructions.

4. Certificate operations look active and automated, but SAN churn highlights inventory hotspots.
   The ecosystem is dominated by 90-day certificates (Let’s Encrypt, GTS), consistent with automation. However, unusually high distinct-certificate counts for certain SANs (including .local.twitter.com) suggest areas where naming/issuance practices could be tightened.

5. No evidence of expired or revoked certificates being actively served.
   Both categories are at zero, a positive operational signal.

---

This data relies entirely on public sources accessible through the Internet without any authentication