This article covers how to setup and use secure Caster connections in SNIP. Secure connections use https 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. This is a feature which was defined in NTRIP Rev2 some time ago and which is now gaining greater deployment as more NTRIP Client software adopts its use.
Background
Secure NTRIP Caster connections using https use TLS/SSL (Transport Layer Security / Secure Sockets Layer) and a system of exchanged security certificates (or CERTs for short) to establish a secure connection. [Transport Layer Security (TLS), is the successor of the Secure Sockets Layer (SSL), which is no longer used but often seen in terminology. The terms “secure socket” or “secure connection” imply its use.] The mechanism used is the same as what your browser is now doing as you read this web page over a secure link. 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. The CERTs used are the same as found on any server. You do not need an understanding of how the security system works to use it. But in the text below we explain a few key concepts; much more detail can be found on-line.
Setup for Remote-Relay Connections
Setting up a secure connection involves simply checking the Use TSL/SSL Connection check box shown below. [Use of the other controls in this dialog are covered in the setup a remote relay connection article.] When this is checked, two changes are also made in the dialog. The check box Use NTRIP Rev2 is also automatically checked (because NTRIP Rev1 does not support secure connections). And the remote connection port is set to 443 – if that field was previously empty or was set to 2101.
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. Consult the documentation for the Caster you will connect to for specific details.
That is all there is to it. When you accept the setup dialog (press the Ok button) SNIP will connect to the remote Caster using the NTRIP User Account credentials the remote Caster provided. 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.
If for some reason the certificate presented by the remote Caster is not valid an error dialog is shown. The reason(s) for this are then presented to the SNIP operator for review to determine if an exemption should be made (if the incorrect CERT should be accepted and used for that specific Caster). The next sections cover this process in greater detail. SNIP will not use an incorrect CERT in the connection process without explicit direction to do so from the operator.
Certificate Correctness
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). 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. Another part of the initial negotiation is to determine how the data will be encrypted for transfer. The CERT lists a number of cipher suites it supports and the client selects which will be used after the negotiation completes. [Aside: When data is transferred from the NTRIP Caster to the NTRIP Client, each packet of data is block encrypted, typically with AES methods. 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.]
Certificates are intended to be used one machine with one domain name, or on set of machines associated with that domain (sub domains). If the NTRIP Caster operator does not ensure that the host name matches the CERT, it will cause an error. Various wild cards can also be used in the CERT name process to expand the use of the CERT and ensure a correct match. Note that CERTs are normally associated with domain names, not IP values (although it is possible to do so). A trivial way to create a “bad” CERT is simply to connect to a Caster using its IP address.
To illustrate this further, consider the popular NTRIP Caster run by the International GNSS Service (IGS.org) found at igs-ip.net on port 2101 (the traditional non-secure connection) and port 443 (the secure connection). If you connect to “ips-ip.net:443” the returned CERT is considered valid because the name and other details all match. 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. If however you connect to “www.ips-ip.net:443″ the returned CERT is considered NOT valid because the the “common name” found in the returned CERT no longer matches. In the error dialog (discussed below) you see “The host name did not match any of the valid hosts for this certificate” displayed. This is a good example of a minor certificate issue that should be corrected or can be ignored. If you were to enter the IP (rather than the domain name), a similar error would be returned.
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. If the NTRIP Caster operator fails to renew the CERT in a timely way, the expired CERT will cause an error.
Many of the fields in the CERT will be empty and this is normal. 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.
All “good” CERTs list who trusts them, pointing to another CERT (representing an organization). This is the CERT of the organization that issued the CERT you are examining. Trust is established and distributed in this way, creating a hierarchical “trust chain” (called CERT chaining). The basic premise is that if you can trust the other CERT, you can safely trust the CERT it has issued. 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. [Aside: You can see the chain of CERTs involved along with each issuer with the dialog below.] In summary, a CERT which is otherwise valid and which has a valid trust chain is accepted by SNIP without the need for operator approval.
Some CERTs do not use a chaining process back to a root anchor. 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. This is fairly common and is not necessarily bad in any way. Various public tools allow anyone to issue such CERTs. 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. For example, the NTRIP Client could get malicious data and be spoofed from such a connection. Better NTRIP Caster deployments will not use self-signed CERTs. In summary, any self-signed CERT is considered incorrect and requires the SNIP operator to approve of its use.
Dealing with Incorrect Certificates
Certificates (CERTs) can be incorrect for a number of reasons, see the prior section. Some of these are of grave concern but many are not, especially in the specialized use case of GNSS corrections. [Unlike a web site doing financial transactions, the relative risk involved is usually much less.] It is up to you, as the SNIP operator, to allow or deny any incorrect certificates from being used. And you must repeat this process for every Caster that presents an incorrect CERT. For multiple mountPts from the same Caster you need to do this only once (as the Caster uses the same CERT for each connection). A list of your prior approved exceptions is kept and reused each time SNIP starts. 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.
Managing incorrect CERTs falls into two general tasks:
- Looking at the error (or errors) from the CERT
- Looking at that the CERT itself, and any related CERTs that make up its validation chain.
SNIP provides two dialogs or order to handle these. Based on the data in these dialogs, the operator either accepts or rejects the presented CERT. When a CERT is rejected, SNIP will no longer attempt to reconnect to the Caster until manually told to reconnect (right-click the context menu in the slot and select Connect).
Viewing the CERT Errors
Whenever a secure connection is made, the remote Caster returns a Certificates (CERT) to establish its own validity. In other words the machine is who it claims to be. When this CERT cannot be fully validated, the error (or errors, as their can be more than one) are displayed in in a dialog box as shown in the below example.
The title of the dialog shows the remote Caster (the domain name and port) to which the connection refers. The details of the CERT itself (and of the other CERTs in its chain) can be examined with the View Certificate Chain button (see next section).
After considering the presented data and the relative risk, the SNIP operator can Accept the connection or Cancel (reject) it and hence the presented CERT. If Accept is not pressed, the connection attempt is stopped and the CERT will continued to be rejected. If Accept is pressed the CERT will be accepted, the connection process is allowed to continue, and the CERT digest value, as well as the NTRIP Caster involved, is added to the list of certificate exceptions.
Viewing the CERT and CERT Chain
The actual CERT chain can be viewed in two ways. From the above errors dialog (press the View Certificate Chain button), or from the right-click context menu of any active secure connection. The display shows various details about the CERT. The most useful of these is the Common Name field which must match the Caster domain and the end date (expiration time). Details about the issuer of the CERT are also shown.
The combo box for the Certificate Path allows selecting any of the CERTs that make up the chain. In the example below one can see that three CERTS were used. The the igs.net CERT was issued by “Let’s Encrypt” which was in turn issued by “Internet Security Research Group” in this example.
Managing the Certificates Exceptions
The digest values of invalid CERTs which have been approved for use are listed (along with the domain name) in a dialog for review. This dialog is opened with the menu command: Misc ⇒ View CERT Exceptions… and is shown below. The collection of prior approved CERTs can be managed (items can be removed) in the below dialog with a double click on any item. An “are you sure” dialog is then presented, and on confirmation the CERT is removed. Items are automatically added to this list when the SNIP operator confirms that an invalid CERT is to used on a given Caster domain.
Viewing the Certificate Chain
Whenever a secure connection is active using a CERT, the right-click context menu for that stream provides the item View Secure CERT used which can be used to bring up the Cert Info dialog to display the full members of the CERT chain. On nonsecure connections this menu item is disabled or not present.
And the tool tip display for the connection also denotes that this is a secure connection. The letter “S” appears in various reports to denote this as well.
Related Topics
Client CERTs
The above process deals with making a secure connection to a remote NTRIP Caster which will provide a suitable certificate for use during the connection negotiation phase. Here the NTRIP Caster (the server element) presents its CERT to the NTRIP client (the end user element) for acceptance. And this is the process which is defined for use in the current NTRIP Rev2 standard. However it represents only one of several possible ways to exchange certificates to establish trust. Another common connection mode found over https has the client element also present its own CERT to the server element to provide a mutual authentication process. This method is not defined in the current NTRIP Rev2 standard, but its use is not prohibited either.
Tip: Recall you can also use the User Account restriction functions to restriction the ways in which a given user may connect. This includes limiting the NTRIP agent they are allowed to connect with.
Running SNIP on a Secure Port
From Rev 3.03 onward, all SNIP models (Lite, Basic, and Pro) can connect to remote secure Casters. In the next release SNIP will itself be able to provide a secure connection port to service connecting NTRIP Client devices (rovers) and NTRIP Server devices (base stations) as well. This feature will require a Pro model of SNIP as well as a suitable SSL/TLS Plug-In module. We can provide suitable certificates (CERTs) for use in your deployment as required as well. Often your ISP can also provide a suitable CERT for use as a service.