{"id":7992,"date":"2024-09-14T00:00:13","date_gmt":"2024-09-14T00:00:13","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=7992"},"modified":"2024-09-14T17:49:38","modified_gmt":"2024-09-14T17:49:38","slug":"secure-caster-connections","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/secure-caster-connections\/","title":{"rendered":"Secure Caster Connections"},"content":{"rendered":"

This article covers how to setup and use Remote-Relay<\/strong> secure Caster connections in SNIP<\/strong><\/span>.\u00a0 Secure connections use https<\/strong> encryption over the TCP\/IP connection (rather than http) to protect the GNSS data from being compromised (intercepted or tampered with), and to allow the validation of the identity of the remote Caster machine.\u00a0\u00a0 This is a feature which was defined in NTRIP Rev2<\/a> some time ago and which is now gaining greater deployment as more NTRIP Client software adopts its use.<\/p>\n

Background<\/h2>\n

Secure NTRIP Caster connections using https<\/strong> use TLS\/SSL\u00a0 (Transport Layer Security \/ Secure Sockets Layer) and a system of exchanged security certificates (or CERTs for short) to establish a secure connection. \u00a0 [Transport Layer Security (TLS), is the successor of the Secure Sockets Layer (SSL), which is no longer used but often seen in terminology.\u00a0 The terms “secure socket” or “secure connection” imply its use.]\u00a0\u00a0 The mechanism used is the same as what your browser is now doing as you read this web page over a secure link.\u00a0 The security layer can be viewed as residing between the NTRIP protocol and the TCP\/IP connection, just as the the security layer for html pages can be viewed as residing between the http protocol and the TCP\/IP connection.\u00a0 The CERTs used are the same as found on any server.\u00a0 You do not need an understanding of how the security system works to use it.\u00a0 But in the text below we explain a few key concepts; much more detail can be found on-line.<\/p>\n

Setup for Remote-Relay Connections<\/h2>\n

Setting up a secure connection involves simply checking the Use TSL\/SSL Connection<\/strong> check box shown below.\u00a0\u00a0 [Use of the other controls in this dialog are covered in the setup a remote relay connection<\/a> article.]\u00a0 When this is checked, two changes are also made in the dialog.\u00a0 The check box Use NTRIP Rev2<\/strong> is also automatically checked (because NTRIP Rev1 does not support secure connections).\u00a0 And the remote connection port is set to 443<\/strong> – if that field was previously empty or was set to 2101.<\/p>\n

\"\"<\/a><\/p>\n

Just like the default caster port of 2101 may vary, the secure caster port can vary between Casters. The remote Caster operator can select any port he wishes, but 443 is most common.\u00a0 Consult the documentation for the Caster you will connect to for specific details.<\/p>\n

On what port to use:<\/strong><\/span> At this time NTRIP does not have a formal recommendation regarding port to use for secure use. If your NTRIP Caster is the only<\/em> server\/service running on the host machine, go ahead and use port 443.\u00a0 But if you are also running web pages, you will want to use that port for https traffic on your web server.\u00a0 In that case, use port 2102.<\/p>\n

That is all there is to it.<\/strong><\/span>\u00a0 When you accept the setup dialog (press the Ok<\/strong> button) SNIP<\/strong><\/span> will connect to the remote Caster using the NTRIP User Account credentials the remote Caster provided.\u00a0 The secure connection negotiation takes place first, and if the certificate presented by the remote Caster is determined to be fully valid, the connection proceeds automatically in the normal way.<\/p>\n

If for some reason the certificate presented by the remote Caster is not<\/em> valid an error dialog is shown.\u00a0 The reason(s) for this are then presented to the SNIP<\/strong><\/span> operator for review to determine if an exemption should be made (if the incorrect CERT should be accepted and used for that specific Caster).\u00a0 The next sections cover this process in greater detail.\u00a0 SNIP<\/strong><\/span> will not use an incorrect CERT in the connection process without explicit direction to do so from the operator.<\/p>\n

Certificate Correctness<\/h2>\n

A certificate (CERT) is considered valid when all of its parameters (such as the domain name on which it can be used) match the host machine using it, when its expiration time has not past, and also when some other entity that you (your host machine) already trusts says the CERT is valid (and is not revoked).\u00a0 Each of these steps are automatically performed when the CERT is presented during an initial negotiation phase of the connection. These steps are considered further in a moment, and a dialog is shown to the operator if any problems are encountered.\u00a0 Another part of the initial negotiation is to determine how the data will be encrypted for transfer.\u00a0 The CERT lists a number of cipher suites it supports and the client selects which will be used after the negotiation completes.\u00a0 [Aside<\/em>: When data is transferred from the NTRIP Caster to the NTRIP Client, each packet of data is block encrypted, typically with AES methods.\u00a0 So the size of the data sent (and therefore the bandwidth required) is not increased by using a secure connection. An important detail for wireless data connections.]<\/p>\n

Certificates are intended to be used one<\/em> machine with one<\/em> domain name, or on set of machines associated with that domain (sub domains). \u00a0\u00a0 If the NTRIP Caster operator does not ensure that the host name matches the CERT, it will cause an error.\u00a0\u00a0 Various wild cards can also be used in the CERT name process to expand the use of the CERT and ensure a correct match.\u00a0 Note that CERTs are normally associated with domain names, not IP values (although it is possible to do so).\u00a0 A trivial way to create a “bad” CERT is simply to connect to a Caster using its IP address.<\/p>\n

To illustrate this further, consider the popular NTRIP Caster run by the International GNSS Service (IGS.org<\/a>)\u00a0 found at igs-ip.net on port 2101 (the traditional non-secure connection) and port 443 (the secure connection).\u00a0\u00a0 If you connect to “ips-ip.net:443<\/strong>” the returned CERT is considered valid because the name and other details all match.\u00a0 Your NTRIP Client DNS service will match “ips-ip.net” to the IP 159.69.124.205 and compare that with the “common name” found in the returned CERT.\u00a0 If however you connect to “www<\/strong>.ips-ip.net:443″ the returned CERT is considered NOT<\/strong> valid because the the “common name” found in the returned CERT no longer matches.\u00a0\u00a0 In the error dialog (discussed below) you see “The host name did not match any of the valid hosts for this certificate” displayed.\u00a0 This is a good example of a minor certificate issue that should be corrected or can be ignored.\u00a0 If you were to enter the IP (rather than the domain name), a similar error would be returned.<\/p>\n

Almost all CERTs have an expiration time, typically one year from the time of issue. In the past, longer periods were commonly used, but this is being curtailed.\u00a0 If the NTRIP Caster operator fails to renew the CERT in a timely way, the expired CERT will cause an error.<\/p>\n

Many of the fields in the CERT will be empty and this is normal.\u00a0 Also note that the certificate process allows adding an arbitrary number of other parameters as well, but these are not typically used. For more details, search online for “subject alternative name extension” or SAN.<\/p>\n

All “good” CERTs list who trusts them, pointing to another CERT (representing an organization). This is the CERT of the organization that issued<\/em> the CERT you are examining. \u00a0 Trust is established and distributed in this way, creating a hierarchical “trust chain” (called CERT chaining).\u00a0\u00a0 The basic premise is that if you can trust the other CERT, you can safely trust the CERT it has issued.\u00a0 This process allows examining the CERT in question to work back to a set of “trust anchors” which is a set of CERTs (root anchors, all pre loaded) which your machine already knows about.\u00a0 [Aside<\/em>: You can see the chain of CERTs involved along with each issuer with the dialog below.] \u00a0 In summary, a CERT which is otherwise valid and which has a valid trust chain is accepted by SNIP<\/strong><\/span> without the need for operator approval.<\/p>\n

Some CERTs do not use a chaining process back to a root anchor.\u00a0 These are called “self-signed” CERTs because the issuer is simply stating “I am and I have issued this CERT” without regard to others confirming this.\u00a0 This is fairly common and is not necessarily bad in any way.\u00a0 Various public tools allow anyone to issue such CERTs.\u00a0 After a review of the CERT details, you may choose to accept such a CERT. While one is advised not to engage in web or financial transactions with such a host, the risks for NTRIP data are fairly modest.\u00a0 For example, the NTRIP Client could get malicious data and be spoofed from such a connection.\u00a0 Better NTRIP Caster deployments will not use self-signed CERTs.\u00a0\u00a0 In summary, any self-signed CERT is considered incorrect and requires the SNIP<\/strong><\/span> operator to approve of its use.<\/p>\n

Dealing with Incorrect Certificates<\/h2>\n

Certificates (CERTs) can be incorrect for a number of reasons, see the prior section.\u00a0 Some of these are of grave concern but many are not, especially in the specialized use case of GNSS corrections.\u00a0 [Unlike a web site doing financial transactions, the relative risk involved is usually much less.]\u00a0 It is up to you, as the SNIP<\/strong><\/span> operator, to allow or deny any incorrect certificates from being used.\u00a0 And you must repeat this process for every Caster that presents an incorrect CERT.\u00a0 For multiple mountPts from the same Caster you need to do this only once (as the Caster uses the same CERT for each connection).\u00a0 A list of your prior approved exceptions is kept and reused each time SNIP<\/span><\/strong> starts.\u00a0 Due to the nature of how CERTS work, if any detail of the presented CERT were to ever change, the prior approval would be void and the new certificate (and its chain) would be reevaluated at that time.<\/p>\n

Managing incorrect CERTs falls into two general tasks:<\/p>\n