Why is QuotaGuard Shield More
Secure Than QuotaGuard Static?
The Story Behind QuotaGuard Shield
Shield was developed at the request of our healthcare customers that required a HIPAA compliant solution that would guarantee a full, end to end encrypted solution and be acceptable for Internet traffic that routes HIPAA, Financial/FinTech, and Personally Identifiable Information (PII), or other secure information.
There were two issues that needed to be addressed to make QuotaGuard Static a truly end to end secure solution.
For security-conscious implementations, even with a full end to end HTTPS connection, the proxy username, password, host, and port are sent in the clear between the internal source and the QuotaGuard proxy. This is true for any HTTP/SOCKS proxy provider (despite what they may tell you).
To enable routing for HTTPS connections, companies had to upload their SSL certificates to an external proxy server, opening up another attack vector that could be exploited in the event of a compromise of the routed traffic or illegitimate network/physical access to the certificate storage location.
Therefore we created QuotaGuard Shield to solve these problems.
Shield Handling of Private Keys
To maximize security, a customer or organization is not permitted to share their SSL certs/private key(s) with a QuotaGuard Shield solution to prevent any PII from being potentially exposed in the case the QuotaGuard system or network traffic is compromised or stolen.
Shield Outbound Service
Shield’s HTTPS and Secure SOCKS outbound service can be used with many languages directly or with our QGPass wrapper program.
When using HTTPS requests through the HTTPS proxy, the data is encrypted from end to end (like an HTTP proxy) and your credentials to the proxy are encrypted as well (unlike an HTTP proxy) and the data is never decrypted at any point in the journey – to include endpoints – because we do not maintain the private key of the sending/receiving organization(s).
Shield Inbound Service
Shield’s inbound proxy uses SSL passthrough.
When sending an HTTPS request through the QG Shield inbound proxies, the HTTP data is encrypted end to end. We use SNI to route your requests to the correct location, so there is no need to give us your SSL certificates and your data is never decrypted at any endpoints, for the same reason, because we do not have the private key of the sending/receiving organization(s).
Regardless of HTTP (QG Static) vs HTTPS proxy (QG Shield), if you are connecting to an HTTPS server through the proxy, the data itself is encrypted from end to end, but the authentication credentials, final destination hostname, and port would still be in the clear with any other proxy service.