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

[Gregory A. Carter]

While everyone knows the current passcode is completely vulnerable, how
much of a problem is it today? As in, I haven't really seen a huge avenue
of abuse via this method; SSL certs and ARRL verifications seems a bit
overblown.

I'm not necessarily suggesting this as a solution but I've had pretty good
success charging $5 for verification and though I don't go through the
hassle of checking paperwork, call signs are checked and abuse is monitored
and I have a controlled means of disabling abusive accounts. After all who
really wants to pay $5 just to a abuse a hobby network that really doesn't
peeve anyone off like IRC or other types of networks.

If someone has ill intent for the network they'll simply DoS it out of
existence. This may sound insensitive but really no one cares about APRS
but us. The most abuse we seem to get is uninformed legit hams with
misconfigured stations.

Greg


On Sat, Mar 29, 2014 at 2:10 AM, Heikki Hannikainen <hessu at hes.iki.fi>wrote:

> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>



-- 
NV6G
OpenAPRS.Net
OpenAPRS iPhone Edition
Find RC sites and weather in your area on iPhone/iPad with WhereBRC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140329/25be4ee8/attachment.html>