Overview

In an era where cyber threats are increasingly sophisticated and prevalent, ensuring the security of our APIs is paramount. Requiring HTTPS for all API calls is a critical measure to safeguard data integrity, confidentiality, and authenticity. HTTPS encrypts the data transmitted between clients and servers, preventing unauthorized access and tampering by malicious actors. By ensuring the use of HTTPS, we protect sensitive information from being intercepted and ensure that our APIs remain a trusted and secure component of our digital infrastructure. This security measure not only aligns with industry best practices, but also fortifies our commitment to maintaining robust data protection standards for our users and stakeholders.

HTTPS Requirement

The absence of HTTPS (Hypertext Transfer Protocol Secure) enforcement poses a significant vulnerability, exposing data to potential compromise.

❗️

All calls made to Bazaarvoice APIs require HTTPS. Starting Aug 30, 2024, every Bazaarvoice API call must use HTTPS in order to return a successful response. All HTTP calls will be returned with a 3XX response containing redirects with an amended URL containing HTTPS.

What is the Impact of HTTPS enforcement?

👍

There will be no impact to any API calls made via HTTPS.

There is no additional validation for secured API calls made to our network. However, all HTTP calls will be validated via an additional flow internally and the following events will follow:

Impact on Bazaarvoice API response:

For every unsecured (HTTP) API call, Bazaarvoice will return a 3XX response.

STATUS 301

Returned on GET/OPTIONS methods.
Error Message : "The resource has been permanently moved to a new location"
Code : "ERROR_MOVED_PERMANENTLY"

Response Body

{
    "Includes": {},
    "HasErrors": true,
    "Offset": null,
    "TotalResults": null,
    "Locale": null,
    "Results": [],
    "Errors": [
        {
            "Message": "The resource has been permanently moved to a new location",
            "Code": "ERROR_MOVED_PERMANENTLY"
        }
    ],
    "Limit": null
}

STATUS 307

Returned on POST/PUT methods
Error Message : "The resource has been temporarily moved to a new location"
Code : "ERROR_MOVED_TEMPORARILY"

Response Body

{
   "Includes": {},
   "HasErrors": true,
   "Offset": null,
   "TotalResults": null,
   "Locale": null,
   "Results": [],
   "Errors": [
       {
           "Message": "The resource has been temporarily moved to the new location",
           "Code": "ERROR_TEMPORARY_REDIRECT"
       }
   ],
   "Limit": null
}

🚧

All POST/PUT requests directed to Bazaarvoice APIs will be temporarily redirected (status code 307) to the new location. While the technical classification is temporary, the server will effectively treat this as a permanent move.

Additional Response headers

Additional Client Facing Impact

🚧

Only calls made via HTTP may be subjected to increased latency and quota utilization or service disruption hazard.

In lieu to the changes made to enforce HTTPS at Bazaarvoice, it would create an impact on:

• Potential Service Disruption: There is a risk of potential service disruption for clients who are making HTTP calls, but have disabled automatic redirection in their implementation. In such cases, the HTTP call would just return a 3XX response, but will not redirect unless the Location header is consumed, leading to no response received for the original API query.
• Increased Latency: The extra validation will subject the latency to increase for HTTP calls by almost 100%, i.e., a call that usually takes 50 ms to return response, may take up to 100 ms post HTTPS enforcement.
• Increased Quota Utilization: Since a new corrected redirect URL is passed in the Location header, Clients would be subjected to making double the amount of API calls for a single operation. This would impact the passkey quota utilization and would increase the utilization by 2x times.

📘

All Clients must ensure that all calls made to Bazaarvoice APIs are via HTTPS.

TLS and Weak Cipher Vulnerabilities

Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over a computer network. It is an evolution of the Secure Sockets Layer (SSL) protocol and is widely used to secure data transferred between web browsers and servers.

However, not all TLS configurations are equally secure. Weak ciphers, which are cryptographic algorithms with known vulnerabilities, can be exploited by attackers to decrypt and tamper with data. This is why using TLS 1.2 with strong ciphers is preferred and considered an industry best practice. TLS 1.2 offers enhanced security features, better performance, and resilience against many vulnerabilities found in earlier versions and weak ciphers. Adopting TLS 1.2 with strong ciphers ensures robust protection of sensitive information, maintaining data integrity and confidentiality in today's digital landscape.

❗️

Bazaarvoice strongly advocates using TLS 1.2 with strong ciphers.

To ensure the use of HTTPS/TLS1.2/Strong Ciphers, it is recommended to consult with the web infrastructure managers responsible for your web/application servers or any edge resources that utilize SSL/TLS to connect to Bazaarvoice APIs. They can provide insight into the server configurations and help verify that only strong cipher suites are enabled. This process will ensure compliance with security best practices and protect against potential vulnerabilities.

End of Support for Weak Ciphers

🚧

Starting Aug 30, 2024, Bazaarvoice will stop supporting all the weak ciphers in TLS.

Weak ciphers are susceptible to cracking and cannot provide as much protection against brute-force decryption when compared to more modern cipher suites, should the traffic be captured, therefore reducing the overall security posture of the application.

📘

You may consult with your respective Web Infrastructure Managers to check if any Weak Ciphers suites are being used across the web/application servers or edge Resources.

Please find the below list entailing the identified weak ciphers that will not be supported going forward.

1. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA)
2. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA)
3. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
4. TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
5. TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
6. TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
7. TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
8. TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
9. TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
10. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA)
11. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA)
12. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
13. TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
14. TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
15. TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
16. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
17. TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
18. TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)

Expected Outcome & Potential Impact

Bazaarvoice has identified the above-mentioned Cipher Suites to pose a significant security vulnerability. Starting Aug 30, 2024 Bazaarvoice will not accept requests using weak ciphers.

Potential Impact can be experienced due to:

• Connection Failure: If the server and client cannot agree on a mutually supported cipher suite, the TLS handshake will fail, resulting in a connection failure. This means that no secure connection will be established, and the data transfer will not proceed.
• Fallback to Stronger Cipher: If the requests are configured with other stronger cipher suites, the server and client will negotiate and select the strongest mutually supported cipher suite available

Outcome will benefit:

• Enhanced Security: By not supporting weak ciphers, the receiving end ensures that only secure and robust encryption methods are used, protecting data integrity and confidentiality. This reduces the risk of vulnerabilities being exploited by attackers.
• Compliance with Security Policies: Not supporting weak ciphers aligns with industry best practices and compliance requirements. This helps maintain the overall security posture and adherence to standards such as PCI-DSS, HIPAA, and GDPR.

Strategies to Mitigate Weak Cipher Exploitation and Enhance TLS Security

To ensure weak ciphers are not exploited, organizations can implement several solutions:

• Cipher Suite Configuration: Configure servers to use only strong, recommended cipher suites. This involves updating server settings to disable weak ciphers and enable strong ones, such as AES-GCM and ChaCha20-Poly1305.
• Regular Security Audits: Conduct regular security audits and vulnerability assessments to identify and address any use of weak ciphers.
• TLS Version Upgrade: Ensure that the latest versions of TLS are supported and enforced. TLS 1.2 or higher should be used, as older versions (e.g., SSL 3.0, TLS 1.0, and TLS 1.1) have known vulnerabilities.
• Server and Application Updates: Keep servers, applications, and libraries up to date with the latest security patches and updates. This helps close any vulnerabilities that may be exploited by weak ciphers.
• Strong Key Management: Implement strong key management practices, including the use of long, random keys and regular key rotation, to ensure that cryptographic keys remain secure.
• Client Configuration: Ensure that clients connecting to the server are also configured to use strong ciphers. This might involve updating client software or providing configuration guidelines to users.

Bazaarvoice strongly advocates security and strives to mitigate any and all potential risks and vulnerabilities. By implementing these security practices, organizations can significantly reduce the risk of weak cipher exploitation and enhance the overall security of their communications.