REST API query shows HTTP in the response
Description
REST API query via browser or curl command
Issue
When performing an API query, why is HTTP is seen in the results in stead of HTTPS?
via browser:
via curl:
$ curl -s -u $user:$pw 'https://lms-odata.aternity.com/aternity.odata/latest/REST_API_AUDIT_LOG?$filter=relative_time(last_1_hours)' | jq -r | more
{
"@odata.context": "https://lms-odata.aternity.com/aternity.odata/v2.0/$metadata_1790186633057,REST_API_AUDIT_LOG,0#REST_API_AUDIT_LOG",
"value": [
{
"ACCOUNT_ID": 0,
"ACCOUNT_NAME": "Default account",
"API_NAME": "$metadata_1790186633057,REST_API_AUDIT_LOG,0",
"API_QUERY": "http://lms-odata.aternity.com/aternity.odata/latest/$metadata_1790186633057,REST_API_AUDIT_LOG,0",
"EVENT_TIMESTAMP": "2026-09-23T13:04:02-04:00",
"HTTP_STATUS_CODE": 200,
"ODATA_API_VERSION": "2.0",
"PAGE_NUMBER": null,
"RESULT_SIZE": null,
"STREAM_ID": null,
"USERNAME": "Administrator"
via browser:
via curl:
$ curl -s -u $user:$pw 'https://lms-odata.aternity.com/aternity.odata/latest/REST_API_AUDIT_LOG?$filter=relative_time(last_1_hours)' | jq -r | more
{
"@odata.context": "https://lms-odata.aternity.com/aternity.odata/v2.0/$metadata_1790186633057,REST_API_AUDIT_LOG,0#REST_API_AUDIT_LOG",
"value": [
{
"ACCOUNT_ID": 0,
"ACCOUNT_NAME": "Default account",
"API_NAME": "$metadata_1790186633057,REST_API_AUDIT_LOG,0",
"API_QUERY": "http://lms-odata.aternity.com/aternity.odata/latest/$metadata_1790186633057,REST_API_AUDIT_LOG,0",
"EVENT_TIMESTAMP": "2026-09-23T13:04:02-04:00",
"HTTP_STATUS_CODE": 200,
"ODATA_API_VERSION": "2.0",
"PAGE_NUMBER": null,
"RESULT_SIZE": null,
"STREAM_ID": null,
"USERNAME": "Administrator"
Solution
This audit log (or any response) only proves that the stored query string contains HTTP but it does not prove the client-to-server connection used HTTP.
One potential reason why this happens is that the API server that runs behind a load balancer/reverse proxy and believes its internal URL is HTTP instead of HTTPS. That device decrypts the traffic and forwards it to the backend application over plain HTTP on the internal network. The application then reconstructs the request URL from what it received — request.scheme / request.url — and writes that into the audit record. So the logged api_query says http://, even though the hop made on the initial request was truly encrypted.
One way to prove transport security is by running your query from Linux using "curl -v". If the handshake completes and there are zero redirects, your traffic was encrypted at your end and the log entry is purely a proxy artifact — cosmetic, not a security finding.
Ex: Here is the same query with the -v flag (verbose) to expose SSL/TLS:
~$ curl -v -s -u $user:$pw 'https://lms-odata.aternity.com/aternity.odata/latest/REST_API_AUDIT_LOG?$filter=relative_time(last_1_hours)' | jq -r | more
* Host lms-odata.aternity.com:443 was resolved.
* IPv6: (none)
* IPv4: 34.200.104.174, 52.20.25.200
* Trying 34.200.104.174:443...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1577 bytes data]
* SSL Trust Anchors:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3786 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / secp256r1 / rsaEncryption
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.aternity.com
* start date: Oct 28 00:00:00 2025 GMT
* expire date: Nov 24 23:59:59 2026 GMT
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* subjectAltName: "lms-odata.aternity.com" matches cert's "*.aternity.com"
* SSL certificate verified via OpenSSL.
* Established connection to lms-odata.aternity.com (34.200.104.174 port 443) from 172.20.206.172 port 48972
* using HTTP/2
* Server auth using Basic with user 'xxxxx@riverbed.com'
* [HTTP/2] [1] OPENED stream for https://lms-odata.aternity.com/aternity.odata/latest/REST_API_AUDIT_LOG?$filter=relative_time(last_1_hours)
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
One potential reason why this happens is that the API server that runs behind a load balancer/reverse proxy and believes its internal URL is HTTP instead of HTTPS. That device decrypts the traffic and forwards it to the backend application over plain HTTP on the internal network. The application then reconstructs the request URL from what it received — request.scheme / request.url — and writes that into the audit record. So the logged api_query says http://, even though the hop made on the initial request was truly encrypted.
One way to prove transport security is by running your query from Linux using "curl -v". If the handshake completes and there are zero redirects, your traffic was encrypted at your end and the log entry is purely a proxy artifact — cosmetic, not a security finding.
Ex: Here is the same query with the -v flag (verbose) to expose SSL/TLS:
~$ curl -v -s -u $user:$pw 'https://lms-odata.aternity.com/aternity.odata/latest/REST_API_AUDIT_LOG?$filter=relative_time(last_1_hours)' | jq -r | more
* Host lms-odata.aternity.com:443 was resolved.
* IPv6: (none)
* IPv4: 34.200.104.174, 52.20.25.200
* Trying 34.200.104.174:443...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1577 bytes data]
* SSL Trust Anchors:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3786 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / secp256r1 / rsaEncryption
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.aternity.com
* start date: Oct 28 00:00:00 2025 GMT
* expire date: Nov 24 23:59:59 2026 GMT
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* subjectAltName: "lms-odata.aternity.com" matches cert's "*.aternity.com"
* SSL certificate verified via OpenSSL.
* Established connection to lms-odata.aternity.com (34.200.104.174 port 443) from 172.20.206.172 port 48972
* using HTTP/2
* Server auth using Basic with user 'xxxxx@riverbed.com'
* [HTTP/2] [1] OPENED stream for https://lms-odata.aternity.com/aternity.odata/latest/REST_API_AUDIT_LOG?$filter=relative_time(last_1_hours)
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
Related Bugs
Attachments
Related Files
NOTICE: Riverbed® product names have changed. Please refer to the Product List for a complete list of product names.
Can't find an answer? Create a case