<div dir="ltr">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.<div>
<br></div><div>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.<br>
<div><br></div><div>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.</div>
<div><br></div><div>Greg</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 29, 2014 at 2:10 AM, Heikki Hannikainen <span dir="ltr"><<a href="mailto:hessu@hes.iki.fi" target="_blank">hessu@hes.iki.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 28 Mar 2014, Andrew P. wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just tried connecting APRSdroid to <a href="http://ssl.aprs2.net" target="_blank">ssl.aprs2.net</a> without a certificate, and it still works (using my old passcode).<br>
<br>
So that isn't keeping me out.<br>
</blockquote>
<br>
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.<br>

<br>
* 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 <a href="http://iad.aprs2.net:14501/" target="_blank">http://iad.aprs2.net:14501/</a>).<br>

<br>
* 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.<br>

<br>
* 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.<br>

<br>
* 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.<br>

<br>
* 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.<br>
<br>
* 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.<br>

<br>
* 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.<br>

<br>
* It's not limited to APRS-IS. It's quite easy to configure for web services: <a href="https://authtest.aprs.fi/" target="_blank">https://authtest.aprs.fi/</a><br>
<br>
* 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 :)<br>
<br>
  - Hessu<br>
<br>
______________________________<u></u>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/<u></u>listinfo/aprssig</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>NV6G<br>OpenAPRS.Net<br>OpenAPRS iPhone Edition<br>Find RC sites and weather in your area on iPhone/iPad with WhereBRC
</div>