[aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

[Heikki Hannikainen]

On Fri, 28 Mar 2014, Andrew P. wrote:

> I just tried connecting APRSdroid to ssl.aprs2.net without a certificate, and it still works (using my old passcode).
> 
> So that isn't keeping me out.

Yup, it's an experimental feature, and naturally, passcode-only clients 
are not rejected, since that would make a lot of users unhappy. The same 
servers still provide normal service on port 14580. Actually, using SSL, 
you're not getting anything extra at this point, it's a proof-of-concept 
showing that it can be done and doesn't break things as such.

* The server just knows for sure that ARRL has given you a certificate, 
and that they do a stronger validation of license status than most APRS-IS 
passcode-giving software authors would do. The server's status page shows 
that knowledge by showing a clickable "Cert" instead of "Yes" or "No" in 
the Validated column (F5VAG-10 is still on http://iad.aprs2.net:14501/).

* The server at this point doesn't do anything else than that, but it 
could be improved to pass that knowledge onwards to other servers together 
with the packets, and then onwards to other clients. For that to be 
useful, the servers also need to authenticate with each other in a strong 
way (not just passcode). aprsc can do SSL between servers.

* At least from overseas, you can easily send in fake documents to ARRL, 
of course, and they will then give you a certificate. This can, however, 
be battled. It takes a couple of weeks for the mailed documents to go 
through, and it takes actual manual work to go through the process of 
*mailing* the documents. The certificate you get is unique, and once it 
turns out to be in the hands of a pirate, that single certificate can be 
rejected by the services by configuration. The pirate then needs to get 
another certificate, and since it's easier and quicker to block the cert 
than to get a new cert, the battle is easy to fight. The balance of effort 
is uneven.

* The services can block based on callsign embedded in the certificate, if 
the callsign itself is invalid (N0CALL, or some P1RATE, or such). The 
services can also block based on certificate identifier, if a pirate has 
obtained a cert for a legitimate callsign assigned to a licensed ham 
somewhere. The legitimate user can continue using his callsign.

* The certificates are digitally signed by the ARRL (or other CA), you 
cannot adjust your own certificate to contain someone else's callsign - 
the certificate won't validate if you alter its contents.

* A lot of people don't want to be involved with the ARRL, but it's not 
limited to ARRL. If other organisations start giving out client 
certificates, and demonstrate that they validate the license status 
properly, the services can be configured to accept the certificates from a 
large number of different Certificate Authorities. Other leagues, clubs, 
APRS software authors. Even commercial entities, as long as they show 
they're doing it right.

* Ah, you want to run this over radio (2.4 GHz or 5 GHz HamWAN data 
links), and you're not allowed to encrypt the data? The server has been 
tuned to accept the use of 'NULL' crypto, where the transferred data is 
_not_ encrypted. You're still authenticated in the beginning with the 
certificate, and the data is tamper-proof (thanks to HMAC), but the data 
contents are not encrypted while in transit. The client app can select 
whether to encrypt, or to not encrypt.

* It's not limited to APRS-IS. It's quite easy to configure for web 
services: https://authtest.aprs.fi/

* Yes, it can be used with UI-View32 - just run a client-side SSL Proxy 
app such as 'stunnel' to make the SSL connection to the server :)

   - Hessu