Moovweb FAQs

ResolvingUpstreamSSL connection issues with Moovweb Infrastructure

One of the possible causes for the 531 Dropped upstream connection is a failure in TLS negotiation between the Moovweb cloud and the upstream customer servers. There are a few things that you can check on your servers to ensure that TLS negotiation with the Moovweb servers is successful.

TLS

The Moovweb servers use TLS 1.2 to connect upstream. Please ensure that your servers support TLS 1.2.

TLS Cipher Suites

We use the default node.js TLS Cipher suite, which is detailed below:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA

Testing your Site

To test whether or not your servers support TLS 1.2, and use the required Cipher Suites, you can perform the following curl on your environment, upstream of Moovweb.

curl -o /dev/null -v https://<your domain>/

You should see the following line in the response to the curl:

* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

You can also use online tools, such as www.sslchecker.com, to check the TLS and Cipher Suites on your server.

If the TLS version is not 1.2, or the Cipher suite is not included in the above list, please reach out to your IT team.

There is currently a bug with the moov_rewriter module. It is causing issues on subdomain projects with strict cookie rewriting on. Cookies are not being rewritten "strictly" in these projects as expected. There is, however, still a way to override cookies and manually edit the "Set-Cookie" headers.

We can use a not-so-secret file under the scripts directory that, by default, is executed by our SDK before actually sending the response to the device and is used as a space to modify and play with the headers of our response using the "headers" variable. So, the step-by-step guide is easy:

Step-by-step guide

Create a new file under the scripts directory called "moov_response_header_transform.js"

Write your MoovJS code.

That's it. You can do a number of things with the variable. You can read more about its use here: http://developer.moovweb.com/modules/moov_stdlib/headers

For now, I'll give you a simple example. What if, you wanted ALL cookies in your subdomain project to have strict domains specific to the mobile subdomain. The strict mode for cookie rewriting is not working, so you have to rewrite them yourself. Heres is what that would look like:

var alreadySetCookies = ctx.env.all_set_cookies.split('::MWDELIM::');

headers.removeAllHeaders("Set-Cookie");

for (var i = 0; i < alreadySetCookies.length - 1; i++) { if (!alreadySetCookies[i].match(/domain/ig)) { alreadySetCookies[i] = alreadySetCookies[i] + "; Domain=" + ctx.env.host; } else { alreadySetCookies[i] = alreadySetCookies[i].replace(/domain=[\s\S]*?.domain\.com/ig, "Domain=" + ctx.env.host); } headers.addHeader("Set-Cookie", alreadySetCookies[i]);}

Things to note in this piece of code

The "ctx.env.all_set_cookies" variable is a long string of all cookie values that have been already set delimited by "::MWDELIM::".

We clear all the Set-Cookie headers after we have already stored all the cookies from the ctx variable. We'll add them after rewriting their domains.

The for loop goes to "length - 1" because the string of cookies ENDS with a "::MWDELIM::", so the split() function will have an empty string as its last element.

We cover all cookies. Once with no specific domain in them and any sort of derivative of the main domain.

Finally, just add a new "Set-Cookie" header with each of your newly rewritten cookie values.

This is a very straight-forward case, but it showcases the simple manipulation of headers in this file.

You can override the user agent in your moov_config.json file, by adding an entry similar to the following:

"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 Safari/536.25"

The user agent that gets sent from Moovweb to the upstream site will now be the one specified above. By default when this is not added, the user agent that gets passed along will come directly from the browser. This allows you to specify the override.

Occasionally Moovweb releases patches and feature upgrades to its moov_builder npm module on which all MoovJS projects depend. To update your existing projects to new version do the following:

Install all dependencies with "npm install"

Install new version of moov_builder with "npm install --save-dev moov_builder". Note that "npm update" will not work if you have "shrinkwrapped" your dependencies.

Check project's package.json file to see the updated version of moov_builder.

If you shrink-wrap dependencies in your project, check project'snpm-shrinkwrap.json file to see updated version of moov_builder.

Commit changes to package.json and optionallynpm-shrinkwrap.json files.

In April 2015, the PCI Security Standards Council stated that starting June 30th, 2016, only TLS v1.1 or higher is acceptable for PCI compliance. Later in December 2015 the Council extended the deadline for discontinuing SSL and TLS v1.0 toJune 30th, 2018. Here is their post for the extension.

"The Payment Card Industry Security Standards Council (PCI SSC) is extending the migration completion date to 30 June 2018 for transitioning from Secure Sockets Layer (SSL) and Transport Layer Security (TLS) v1.0 to a secure version of TLS (currently v1.1 or higher). These dates provided by PCI SSC as of December 2015 supersede the original dates issued in both PCI Data Security Standard v3.1 (PCI DSS 3.1) and in the Migrating from SSL and early TLS Information Supplement in April2015."

Moovweb has added the HTTP header "X-SSL-Proto"whichcontains the TLS version: TLSv1, TLSv1.1 or TLSv1.2. Customers can use this header to selectively redirect users who do not meet the TLS version requirement the customer has defined.

How to block TLS 1.0 requests

Customers who want to reject TLS 1.0 request need to add a few lines of code to their project to redirect these users to an error page. Here is an example of how to do this.

Detect the TLS version and set a flag

Insert these lines near the top of themodule.exports = function() {in./scripts/index.js:

module.exports = function() { if (env.x_ssl_proto === 'TLSv1') { fns.export('Location', '/error_page.html'); env.response_code = 302; return { body: '', htmlparsed: false }; }

Valid Values for the X-SSL-Proto Header

TLSv1

TLSv1.1

TLSv1.2

TLSv1.3 (future)

Testing Locally with the Moov SDK

Note: The Moov SDKdoes not injectthe X-SSL-Proto header. You can test locally by manually inserting the X-SSL-Proto header into your requests. e.g.

curl -H "X-SSL-Proto: TLSv1" localhost/

This injects the X-SSL-Proto header into your requests. In this situation you do not need to use HTTPS to test.

Deploy your project to the MoovCloud

Once you deploy your project to the MoovCloud, you can test your code by browsing to your project via HTTPS.

Note: In the MoovCloud, the X-SSL-Proto header injected is only injected on HTTPS requests. HTTP requests will not have the X-SSL-Proto header.

Debugging Your Requests

The X-SSL-Proto header is injected into the requests Moovweb makes to the upstream host.This header is not returned to the web browser. If you want to see the X-SSL-Proto header that send to the upstream host, add the following query parameter to your URL.

https://<your domain>/?__moov_debug_options=get-upstream-headers

This query parameter causes MoovCloud to return a debug HTTP header "x-moov-debug-upstream-headers" which contains the list of HTTP headers send to the Adapt code and the upstream host. E.g.

x-moov-debug-upstream-headers:

"GET / HTTP/1.0Host: developer.moovweb.com Connection: close

X-Http2-Proto: h2

X-SSL-Proto: TLSv1.2

accept: */*

user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Overwatch) Chrome/51.0.2704.103 Safari/537.36

X-Forwarded-For: 209.136.227.218

Accept-Encoding: gzip,deflate

Via: 1.0 moovweb"

In this example you can see the X-SSL-Proto header returns "TLSV1.2"