<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Do we really need it. ? </div><div><br></div><div>Given that the current situation is open to abuse </div><div><br></div><div>Seems the pass code is just a pain </div><div><br></div><div>The only security the current setup offers is "if you know about it" rather than true security </div><div><br></div><div>Andrew <br><br>Sent from my iPhone</div><div><br>On 1 Apr 2014, at 8:03 am, <a href="mailto:pfbram@comcast.net">pfbram@comcast.net</a> wrote:<br><br></div><blockquote type="cite"><div><div style="font-family: Arial; font-size: 12pt; color: #000000">The SSL would be for a (separate) verification/authentication system, not the APRS packets themselves, to ensure that the user's app. password doesn't travel plain-text, and is not sniffable. It would be largely a self-policing model. Each operator would maintain his own profile, keeping it current with his callsign, passcode, his IGATE's current IP address, etc. The only thing that would need to be added to the T2 network is (a) noting the IP in the incoming packets and (b) some sort of API to ensure that the IP matches the one noted as "valid+current" by the operator in a hypothetical profile/validation system. I agree, this approach has its problems.<br><br>I've worked with SSL, Shibboleth, made my own certs/CA's, etc. and other systems professionally for several years. I'd definitely advise against Shibboleth due to its complexity, moving parts, etc.<br><br>Usually it's a matter of approaching the "business problem" itself from a different angle, not just throwing technology at it. Who knows? Maybe there is something to be gained with VPN's, SSL + ssh keys, GnuPG, etc. Certainly with security there is no such thing as a single magic bullet.<br><br>But if you could better manage your own IGATE/call against someone spoofing it -- and have a tool on hand to easily block out/filter troublesome stations (point-and-click), then you'd have a more resilient system -- driven mainly by (a) more information available to you and (b) self-policing.<br><br>Paul / KD0KZE<br><br><hr id="zwchr"><b>From: </b>"Jason KG4WSV" <<a href="mailto:kg4wsv@gmail.com">kg4wsv@gmail.com</a>><br><b>To: </b>"TAPR APRS Mailing List" <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>><br><b>Sent: </b>Monday, March 31, 2014 4:28:15 PM<br><b>Subject: </b>Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption<br><br>On Mon, Mar 31, 2014 at 3:47 PM, <<a href="mailto:pfbram@comcast.net">pfbram@comcast.net</a>> wrote:<br>> Just thinking out loud here, but how about a separate<br>> authentication/verification system in which I/SGATE operators login to an<br>> SSL<br><br>Involving SSL doesn't magically make a system secure. SSL is about<br>encrypting traffic in flight - that's it. Forcing use of SSL can<br>provide some measure of authentication, based on the whole CA system.<br><br>> And it would require a<br>> centralized database.<br><br>That little aside _is_ the problem. Who do you trust? Who do you<br>trust to keep a list of people that can be trusted?<br><br>For any authentication system to work, someone has to keep a list, and<br>then be willing to deal with all the extra work involved in certifying<br>everyone on the list.<br><br><br>I'm with Steve K4HG on this one - as far as APRS is concerned all I'm<br>seeing are solutions in search of problems.<br><br>-Jason<br>kg4wsv<br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br><a href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>aprssig mailing list</span><br><span><a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a></span><br><span><a href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a></span><br></div></blockquote></body></html>