sl-service-account
commented
7 years ago Chaser Zaks commented at 2017-07-23T13:09:14Z
As someone who uses LetsEncrypt on their web servers, I highly support the inclusion of the LetsEncrypt root cert on the LSL http.
How would you like the feature to work?
Let's Encrypt (https://letsencrypt.org/) is a recent development in SSL, providing zero-cost certificates to end users. Modern browsers accept their certificates as valid.
However, when attempting to connect to a server which uses such a certificate from an LSL object, using the llHTTPRequest function, you receive a 499 http error code. You're forced to use <HTTP_VERIFY_CERT, FALSE> in the parameter list when making the function call, which defeats half the purpose of utilizing https in the first place.
Please add the necessary trusted authorities to whatever system you have handling certificate verification for LSL http requests.
Additionally, while this would require significantly more work, it would be of great benefit to anyone using scripted http communications if you would have your lsl object callback url domains set up to utilize these free certificates. The certificates which are currently in use are not valid (They're self-signed certificates which can't be verified properly).
Switching to the use of Let'sEncrypt-issued certificates would improve security and not require the administrator of the remote server to either have the server-side code ignore certificate validity, or install LL's CA certificate as a trusted authority for that server.
Why is this feature important to you? How would it benefit the community?
This is important because the current state of affairs means that for anyone using letsencrypt.org issued certificates, verification must be disabled in order to have your LSL objects communicate with your remote server. Since LSL object callback urls utilize self-signed certificates already, this means that the connection is vulnerable to man-in-the-middle attacks in both directions.
Effectively, neither the remote server, nor the LSL object, can verify the identity of the other, which is part of what makes SSL secure. Since you can't know for certain that the certificate you've received came from the entity you expect it to, you don't know whether some party in between the two points has intercepted and swapped the certificates, allowing them to listen in on what should be a secure encrypted communication.
This problem could be solved in the LSL->Server direction simply by adding the proper trusted authority certificates to the validation system so that letsencrypt.org issued certificates validate properly, and the LSL object can then know with reasonable certainty that it is communicating directly with the intended remote server, and the communications will not be intercepted.
In the Server->LSL callback direction, this would require the implementation of an automated ACME protocol system to acquire such free certificates from a service such as letsencrypt.org. This would enable the server to be relatively certain it was connected directly through to an object callback.
Though this is lower priority as at present, installing LL's CA certificate as trusted on the remote server is a usable workaround.
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-134041 | | Summary | Please support "Let's Encrypt" SSL certificates for llHTTPRequest | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | kellySnugglebunnyCuddlesworth (kellysnugglebunnycuddlesworth) | | Created at | 2017-07-21T18:44:12Z | | Updated at | 2017-07-26T18:28:24Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2017-07-23T08:09:13.848-0500', 'How would you like the feature to work?': "Let's Encrypt (https://letsencrypt.org/) is a recent development in SSL, providing zero-cost certificates to end users. Modern browsers accept their certificates as valid.\r\n\r\nHowever, when attempting to connect to a server which uses such a certificate from an LSL object, using the llHTTPRequest function, you receive a 499 http error code. You're forced to use [HTTP_VERIFY_CERT, FALSE] in the parameter list when making the function call, which defeats half the purpose of utilizing https in the first place.\r\n\r\nPlease add the necessary trusted authorities to whatever system you have handling certificate verification for LSL http requests.\r\n\r\n\r\nAdditionally, while this would require significantly more work, it would be of great benefit to anyone using scripted http communications if you would have your lsl object callback url domains set up to utilize these free certificates. The certificates which are currently in use are not valid (They're self-signed certificates which can't be verified properly).\r\n\r\nSwitching to the use of Let'sEncrypt-issued certificates would improve security and not require the administrator of the remote server to either have the server-side code ignore certificate validity, or install LL's CA certificate as a trusted authority for that server.", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "This is important because the current state of affairs means that for anyone using letsencrypt.org issued certificates, verification must be disabled in order to have your LSL objects communicate with your remote server. Since LSL object callback urls utilize self-signed certificates already, this means that the connection is vulnerable to man-in-the-middle attacks in both directions.\r\n\r\nEffectively, neither the remote server, nor the LSL object, can verify the identity of the other, which is part of what makes SSL secure. Since you can't know for certain that the certificate you've received came from the entity you expect it to, you don't know whether some party in between the two points has intercepted and swapped the certificates, allowing them to listen in on what should be a secure encrypted communication.\r\n\r\nThis problem could be solved in the LSL->Server direction simply by adding the proper trusted authority certificates to the validation system so that letsencrypt.org issued certificates validate properly, and the LSL object can then know with reasonable certainty that it is communicating directly with the intended remote server, and the communications will not be intercepted.\r\n\r\nIn the Server->LSL callback direction, this would require the implementation of an automated ACME protocol system to acquire such free certificates from a service such as letsencrypt.org. This would enable the server to be relatively certain it was connected directly through to an object callback.\r\n\r\nThough this is lower priority as at present, installing LL's CA certificate as trusted on the remote server is a usable workaround.", } ```