The SNIP Caster fully supports both Secure and UN-secure Rev2 connections per the current NTRIP standards (as well as legacy Rev1 formats which are not secure). You can connect to the RTK2go Caster with these methods and be assured of a correct standards protocol exchange. An NTRIP Caster listens on a predefined port (2101 and 2102 in this case) and one of these is unsecure (port 2101) while the other (port 2102) is secure (and will not accept unsecure connections). But the security certificate to be used (the CERT) is selected by the Caster operator and can range from good to bad. This article describes some of the different CERT formats you will see in the world and what to do about them.
What is a secure connection?
From NTRIP Rev2 onward, which was published over a decade ago, there has been support for secure Caster connections (that is, connections that use SSL/TLS or what is often called https). However market adoption of Rev2 (also called Version 2) has been very slow. Less than one out of ten devices routinely uses it, and typically these are higher grade devices. Lower end devices such as those using Ublox f9 modules, or devices that use open source code (such as RTKLIB) often do not support Rev2 connections or secure connections (which by definition must also be Rev 2).
A secure connection simply uses SSL/TLS on top of a normal TCP/IP socket to scramble the data being exchanged to protect it from eavesdropping or tampering. A block cypher is used, scrambling the transmitted data without making the messages any longer (in other words it does not cost additional bandwidth to do this). When the TCP/IP connection is first made, an initial exchange determines what security protocols will be used. If the two parties can agree on a common method, the connection is created. The NTRIP Caster has a CERT that it sends to the connecting device. That CERT has a list of supported encryption methods and some identifying details about the Caster to establish its claim of who it is. The NTRIP Caster also has a private key (which it does not share with anyone else) that is used to sign the data it will send out. The receiving party, armed with the CERT (which is public and can be safely shared with anyone) and the unique setup details the two of them just established, can decode this data back into a useful format (which in NTRIP is typically RTCM messages).
There is a general desire in the NTRIP standards community, as well as in the RTCM SC-104 committee (the parent organization that oversees the the NTRIP standard and publishes the RTCM messages) that all NTRIP Client devices now use both the Rev2 protocol format and secure connections when conditions allow it.
RTCM has also published a “best practices” paper to help NTRIP Client device developers understand the details required. Please read it if you develop such products. It is free to download and can be found at: https://rtcm.myshopify.com/products/rtcm-paper-2023-sc104-1344-ntrip-client-devices-best-practices
How does this play in RTK2go?
As you probably are aware, RTK2go uses a copy of the SNIP NTRIP Caster Pro model behind the scenes. We run a non-secure legacy Caster connection for Rev1 and Rev2 devices on port 2101. We run a secure Caster connection on port 2102 which REQUIRES that Rev2 be used and which creates a secure connection using the CERT that has been loaded into it. For the remainder of calendar year 2024 we will be rotating the type of CERTs that are used to allow developers to experience different CERTs, signed (authorized) by different parties. You can find the current CERT described on this page (see What CERT is in use right now below). The CERTs used will typical be changed at mid-day on Sunday every 2 weeks. After this four month period, in 2025, we will simply use a fully valid RTK2go signed CERT.
We suggest you try connections to RTK2go on port 2102 with the different CERTs to ensure that your NTRIP software correctly alerts you to any CERT problems and allows you to accept or reject a CERT based on those finding. All of these CERTs will correctly encrypt the data, the only “errors” will be in the meta data details of ownership (is the CERT self-signed, it is still within a valid date range, etc.).
What is a self signed CERT?
A self-signed CERT is one created by an individual or firm that was not “chained” back to a trust anchor (linked to a more trusted source, also called a trust chain). For financial operations (aka banking) you would definitely want any CERT you depended on to be signed by a Certificate Authority (CA) to avoid fraud. That is much less of a concern here. It is also important to know that the strength of the resulting encryption is the same for any self-signed CERTs as it is for those issued by a Certificate Authority. In both case it is very hard to eavesdrop or tamper with the message content without access to the private key that was used (it depends more on what encryption suite is used). The primary issue with accepting a self-signed CERT is how important it may be to you to know for sure the other party is who they claim to be. We cannot make that judgment for you, but for NTRIP uses this is typically not a great concern. You might, for example, be more concerned if the CERT is past its defined useful life time, or again perhaps not.
Any of these, and host of other details, SHOULD cause the CERT presented by the Caster to be questioned by NTRIP Client or Server device. And the typical best GUI response is to show the CERT to the end user and request what direction to take (aka This CERT is bad because of <some issue> do you wish to accept it and proceed?). And a good GUI then allows the option of saving that decision for future use. If the CERT is well formed and comes from a known Certificate Authority, it is typically accepted without any user intervention.
What CERT is in use right now?
This section shows the CERT that RTK2go is currently using on port 2102. Ideally the connecting NTRIP devices would allow checking and display some of this same information and ask the end user to accept or reject the CERT.
Synopsis: This is a self-signed CERT (issued by rtk2go.com but not in turn anchored back to any CA) but is completely valid in every other respect. Note also that it is valid for ~ten years; current best practices limit this to one year for new CERTs.
See Also:
If you are setting this up on your own copy of SNIP, these articles may also be of use to you: