feat: adds options to bypass SSL validation #837
Conversation
EverlastingBugstopper
added
the
feature 🎉
Co-authored-by: Jesse Rosenberger <git@jro.cc>
Co-authored-by: Jesse Rosenberger <git@jro.cc>
| @@ -265,6 +265,13 @@ If you use a version control system besides Git, you can use the environment var | |||
|
|
|||
| Currently, only Git is fully supported by Apollo Studio. | |||
|
|
|||
| ## Bypass TLS/SSL Validation | |||
There was a problem hiding this comment.
"Bypassing TLS/SSL validation" (lowercase validation)
| @@ -265,6 +265,13 @@ If you use a version control system besides Git, you can use the environment var | |||
|
|
|||
| Currently, only Git is fully supported by Apollo Studio. | |||
|
|
|||
| ## Bypass TLS/SSL Validation | |||
|
|
|||
| In some configurations (often on internal networks) users may need Rover to communicate over encrypted channels (e.g., HTTPS) but avoid the more stringent digital certificate verifications which validate hostnames or may even wish to bypass the digital certificate validation entirely. This is generally not recommended and considered to be much less secure but for cases where it's necessary, there are two flags you can use to configure how Rover validates HTTPS requests: | |||
There was a problem hiding this comment.
Replace all instances of "may" with "might" where equivalent
Comma after "networks)"
"users may need" -> "you might need"
"which validate hostnames" -> "that validate hostnames." (end sentence)
"or may even wish" -> "You might even need"
|
|
||
| In some configurations (often on internal networks) users may need Rover to communicate over encrypted channels (e.g., HTTPS) but avoid the more stringent digital certificate verifications which validate hostnames or may even wish to bypass the digital certificate validation entirely. This is generally not recommended and considered to be much less secure but for cases where it's necessary, there are two flags you can use to configure how Rover validates HTTPS requests: | ||
|
|
||
| - The `--insecure-accept-invalid-hostnames` flag will disable hostname validation. If hostname verification is not used, any valid certificate for any site will be trusted for use from any other. This introduces a significant vulnerability to man-in-the-middle attacks. |
There was a problem hiding this comment.
"will disable" -> "disables"
"man-in-the-middle" -> "person-in-the-middle" ?
There was a problem hiding this comment.
"any valid certificate for any site will be trusted for use from any other" <- Not 100% sure what this means?
There was a problem hiding this comment.
"any valid certificate for any site will be trusted for use from any other"
if i understand correctly (this is yanked pretty much directly from the underlying library's docs) it'll just skip the step where it compares a specified hostname (like api.apollographql.com) to your local certs, meaning a cert for maliciouscert.com could be used in its place (but sometimes skipping this check is desirable on internal networks)
There was a problem hiding this comment.
|
|
||
| - The `--insecure-accept-invalid-hostnames` flag will disable hostname validation. If hostname verification is not used, any valid certificate for any site will be trusted for use from any other. This introduces a significant vulnerability to man-in-the-middle attacks. | ||
|
|
||
| - The `--insecure-accept-invalid-certs` flag will disable certificate validation. If invalid certificates are trusted, any certificate for any site will be trusted for use. This includes expired certificates. This introduces significant vulnerabilities, and should only be used as a last resort. |
There was a problem hiding this comment.
"will disable" -> "disables"
"will be trusted" -> "is trusted"
This fixes #720 by introducing two new flags to control Rover's client configuration.
From the docs attached to this PR:
Bypass SSL/TLS Validation
Sometimes, you may want to perform HTTPS requests from Rover, but skip validation checks. This is generally not recommended and insecure, but there are two flags you can use to configure how Rover validates HTTPS requests.
The
--insecure-accept-invalid-hostnamesflag will disable hostname validation. If hostname verification is not used, any valid certificate for any site will be trusted for use from any other. This introduces a significant vulnerability to man-in-the-middle attacks.The
--insecure-accept-invalid-certsflag will disable certificate validation. If invalid certificates are trusted, any certificate for any site will be trusted for use. This includes expired certificates. This introduces significant vulnerabilities, and should only be used as a last resort.