[aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption
hessu at hes.iki.fi
Sat Mar 29 03:10:42 CDT 2014
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
* 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
* 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 :)
More information about the aprssig