Infrastructure (Encryption and TLS)

Documentation Mercado Libre

Check out all the necessary information about APIs Mercado Libre.

Last update 06/04/2026

Infrastructure: Encryption and transport security

All communication between the end user, the integrating application, and the Mercado Libre APIs travels over the internet, a public network where data can be intercepted, read, or modified by attackers.

Transport encryption (TLS) is the first line of defense that protects this communication.

What do we protect with TLS?

Data interception - Confidentiality: data will be encrypted, unreadable by third parties.
Modification in transit - Integrity: TLS guarantees that the information has not been modified during transit.
Authenticity - Server identity: through digital certificates, TLS assures the user that the remote server "is effectively who it claims to be", this prevents your organization's name from being used to build phishing sites.

An incorrect TLS implementation can result in:

Theft of access tokens (ATO).
Customer information leakage.
Unauthorized data manipulation.
Loss of trust.
Regulatory non-compliance: PCI DSS, LGPD, GDPR among others.

TLS Requirements

Secure TLS versions are required, such as: TLS 1.3 (recommended) or TLS 1.2. TLS versions (1.0 and 1.1) have known vulnerabilities that allow attackers to decrypt communications. It is not enough to "have HTTPS" - the version and configuration of the protocol are critical.

Recommended cipher suites

For TLS 1.3 (ideally)

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256

For TLS 1.2 (accepted)

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Non-accepted cipher suites

Any suite that uses:

RC4 (vulnerable)
DES/3DES (weak)
MD5 (broken)
CBC mode without AEAD (vulnerable to padding oracle)
RSA key exchange without ECDHE (no forward secrecy)
NULL encryption
EXPORT ciphers

Problem visualization

❌ WITH TLS 1.0 or 1.1 (vulnerable):

Your App --------------------------------► API MercadoLibre
         |
    [Attacker]
         |
         +-- Can exploit known vulnerabilities
             such as BEAST, POODLE, etc. to decrypt
             your tokens and data.

✅ WITH TLS 1.2+ (secure):

Your App ════════════════════════════════► API MercadoLibre
         |
    [Attacker]
         |
         +-- Cannot decrypt the communication.
             Data is protected.

How to verify which TLS version my server uses?

Option 1: use SSL Labs

Go to: https://www.ssllabs.com/ssltest/
Enter the domain of the integrating application (e.g.: yourapp.com)
Wait for the evaluation to complete.
Look for the "protocols" section

Result in SSL Labs:

Result	Action
TLS 1.3: Yes, TLS 1.2: Yes, TLS 1.1: No, TLS 1.0: No	✅ Correct
TLS 1.1: Yes or TLS 1.0: Yes	❌ Disable old versions

Option 2: verify with commands via a terminal on the server

# Check if TLS 1.3 is enabled (recommended)
openssl s_client -connect yourdomain.com:443 -tls1_3

# Check if TLS 1.2 is enabled (should work)
openssl s_client -connect yourdomain.com:443 -tls1_2

# Check if TLS 1.1 is disabled (should fail)
openssl s_client -connect yourdomain.com:443 -tls1_1

# Check if TLS 1.0 is disabled (should fail)
openssl s_client -connect yourdomain.com:443 -tls1

Command	Expected result	Meaning
`-tls1_3`	Successful connection	✅ TLS 1.3 enabled (ideal)
`-tls1_3`	Connection error	⚠️ TLS 1.3 not available (acceptable if TLS 1.2 works). Enabling it is recommended
`-tls1_2`	Successful connection	✅ TLS 1.2 enabled (minimum required)
`-tls1_2`	Connection error	❌ TLS 1.2 not enabled (Serious problem), it is necessary to enable it
`-tls1_1, -tls1`	Connection error	✅ TLS 1.1 disabled (correct). Otherwise they must disable it as soon as possible

Note:

The parameter -tls1_3 requires OpenSSL 1.1.1 or higher. If your OpenSSL version is older, update it or use SSL Labs to verify TLS 1.3.

Certificate Requirements

The digital certificate is the "identity document" of a server. When an application connects to https://api.mercadolibre.com, the SSL certificate allows it to verify that it is really talking to Mercadolibre and not with an attacker.

Disabling certificate validation is equivalent to:

Accepting an identity document without looking at the photo.
Signing a contract without verifying who is presenting it to you.
Handing the keys to your house to anyone who claims to be the locksmith.

That is why the integrating application must:

Validate certificates

Always have certificate verification enabled in production.

❌ With certificate validation disabled:

Your app accepts ANY certificate, even a fake one from an attacker.

Your App ----------► [Attacker with fake cert] ----------► MercadoLibre
                            |
                            +-- Reads and modifies EVERYTHING

✅ With validation enabled:

Your app rejects invalid or fake certificates.

Your App ══════════════════════════════════════════► MercadoLibre
             [Attacker] ✗ Cannot intercept

Examples of bad practices and their correct implementation.

In Python:

# ❌ DANGER!
requests.get(url, verify=False)

# ✅ The correct way:
requests.get(url)  # Validates by default
# or explicitly:
requests.get(url, verify=True)

In Node.js:

// ❌ DANGER!
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'

// ✅ The correct way is to do nothing special, it validates by default.

In PHP:

# ❌ DANGER!
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

# ✅ The correct way:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);

For other languages look for these dangerous patterns (common examples):

Language	Dangerous pattern	If you find it:
Java	`TrustAllCerts` and/or `HostnameVerifier` that returns true	❌ Serious problem, using the default SSLContext already verifies correctly
C#/.NET	`ServerCertificateValidationCallback` = ... that returns true	❌ Serious problem, it is recommended not to configure any callback as it uses default validation
Go	`InsecureSkipVerify: true`	❌ Serious problem, using the default client already verifies
cURL	`--insecure` or `-k`	❌ Check if it is production, remove the –insecure or -k flag

Verify hostname

The CN (Common Name) or SAN (Subject Alternative Name) must match the domain you are connecting to.

❌ INCORRECT:

You connect to: api.mercadolibre.com
Certificate says: *.example-attacker.com

→ Without hostname verification, your app accepts this fake certificate

✅ CORRECT:

You connect to: api.mercadolibre.com
Certificate says: *.mercadolibre.com (matches)

→ Your app verifies that the name matches before continuing

How to validate it?

Most modern HTTP libraries verify the hostname by default. Verify that it has not been explicitly disabled:

Language	Dangerous pattern	If you find it:
Python	`assert_hostname=False`	❌ Problem, remove the dangerous pattern or set the value to true
Node.js	`checkServerIdentity: () => undefined`	❌ Problem, remove this option entirely
Java	`setHostnameVerifier(NoopHostnameVerifier)`	❌ Problem, remove this line (use default verifier)
Go	`InsecureSkipVerify: true`	❌ Problem, remove this line (use default verifier). Or set the value to true

Verify the validity of an SSL certificate

To verify generation dates, expiration dates, hostname, TLS versions, cipher suites, and more, we can use the tools from SSL Labs.

SSL Labs analyzes your server and gives you a grade from A+ to T that summarizes the security level, where A+ corresponds to an optimal security level and T a low security level.

Grade	Meaning	What to do?
A+	Excellent, optimal configuration with HSTS	✅ Perfect, do not change anything
A	Very good. Meets all best practices	✅ Acceptable for production
B	Good, but with possible improvements	⚠️ Review recommendations
C - T	Insecure configurations	❌ Fix before production

Example: verify the Mercadolibre certificate:

Go to https://www.ssllabs.com/ssltest/
Query: api.mercadolibre.com
You will see the grade

Example: verify YOUR certificate:

Go to https://www.ssllabs.com/ssltest/
Query: your-domain.com
You will see the grade: If the grade is A or B you will be ready for production. If it is C or lower you must review the recommendations and once corrected run the test again

How to verify that my integrating application complies with this section?

Security is not a state, it is a continuous process. A configuration that was secure yesterday may not be today: certificates expire, new vulnerabilities are discovered in cipher suites, libraries are updated and change default behaviors, insecure code can be introduced.

That is why it is important to ask ourselves periodically whether:

Does my application use TLS 1.2 or higher?
Do I have certificate validation enabled?
Are my SSL/TLS dependencies up to date?
Does my server have a valid and current certificate?
Am I frequently validating certificate change dates?

References

OWASP TLS cheat sheet: comprehensive guide to TLS best practices.
SSL Labs: tool to analyze the TLS configuration of your server.
Mozilla SSL configuration generator: generates secure TLS configuration for your server.
CWE-295: documentation on improper certificate validation.
testssl.sh: command-line tool for auditing TLS.

Glossary

Term	Meaning
TLS	Transport Layer Security - Protocol that encrypts communication between your app and the server. Secure versions: 1.2 and 1.3
SSL	Secure Sockets Layer - Old version of TLS, no longer secure. Do not confuse with TLS
HTTPS	HTTP + TLS = Encrypted web communication. The "S" stands for "Secure"
Digital certificate	Electronic document that verifies the identity of a server (like a digital ID card)
CA (Certificate Authority)	Trusted entity that issues certificates (e.g.: DigiCert, Let's Encrypt, Comodo)
Cipher Suite	Set of algorithms used to encrypt a connection

Next: Identity and access management.