<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Not sure how people use a load balancer; it does make a failover arrangement a bit more complicated, admittedly.<div><br></div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Apr 4, 2025, at 11:46, Shawn Stoddard <stoddard@pobox.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><title></title><div>That kills the poor man’s load balancer that is in-use or at least complicates it. </div><div><br></div><div>On Fri, Apr 4, 2025, at 11:07, Erik Beck wrote:<br></div><blockquote type="cite" id="qt" style=""><div>Another idea might be to extend the existing hash algorithm to include a server-specific 'salt'. That way the codes can't be reused ad nauseam by simple cut and paste.<br></div><div><br></div><div><div>Erik, N7FYO <br></div><div><div><br></div><div dir="ltr">Sent from my iPhone<br></div><div dir="ltr"><div><br></div><blockquote type="cite"><div>On Apr 4, 2025, at 03:17, Erik Finskas <erik.finskas@gmail.com> wrote:<br></div></blockquote></div><blockquote type="cite"><div dir="ltr"><div><br></div><div dir="ltr"><div>It is true that the APRS passcode 'authentication' is not secure enough when reflected to modern security criterias and is widely misused to flood APRS-IS.<br></div><div><br></div><div>There are some other methods possible to prevent flooding from regular users by rate-limiting the connection, and/or enhanced authentication method for igates and servers with increased traffic rates.<br></div><div><br></div><div>A good reminder is that we all already have a free PKS solution enrolled through LOTW, which allows everyone to have a certificate to use for authentication purposes. It (only) requires some development to make it usable for user authentication to APRS-IS.<br></div><div><br></div><div>73,<br></div><div>Erik OH2LAK<br></div></div><div><br></div><div class="qt-gmail_quote qt-gmail_quote_container"><div dir="ltr" class="qt-gmail_attr">On Thu, 3 Apr 2025 at 19:47, Scott Miller <<a href="mailto:scott@opentrac.org">scott@opentrac.org</a>> wrote:<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>I'm sorry if that came out a little harsh - I haven't finished my coffee <br></div><div> yet this morning.<br></div><div> <br></div><div> The instances I've seen of abuse have usually been fairly isolated and I <br></div><div> think could be adequately addressed by coordinated temporary IP bans. <br></div><div> The APRS-IS core operators would be in a better position to discuss <br></div><div> countermeasures<br></div><div> <br></div><div> Scott<br></div><div> N1VG<br></div><div> <br></div><div> On 4/3/2025 9:24 AM, Scott Miller wrote:<br></div><div> > Who are you suggesting should take on the burden of verifying the <br></div><div> > identity of everyone who wants to connect? Who defines the access <br></div><div> > criteria? Are you going to implement different tiers of access for <br></div><div> > internet to RF gating than for internet-only (e.g., flood monitors)?<br></div><div> ><br></div><div> > "Everyone can read the APRS-IS data stream" is a feature, not a bug. <br></div><div> > It's always been open for public access. It'd be impossible to prevent <br></div><div> > an authorized user from mirroring the stream, and someone definitely <br></div><div> > would.<br></div><div> ><br></div><div> > There's no authentication on the RF side and you can post <br></div><div> > disinformation that way, too. If you've got specific examples of abuse <br></div><div> > that's happening, present them and we can tackle them. This is a <br></div><div> > discussion that's been had many times over the past 20+ years and a <br></div><div> > solution has to be more than technological. There are fundamental <br></div><div> > policy questions about who the system belongs to, what traffic is <br></div><div> > permissible, and who should have access that are much tougher problems <br></div><div> > than selecting a hash algorithm.<br></div><div> ><br></div><div> > Scott<br></div><div> > N1VG<br></div><div> ><br></div><div> > On 4/3/2025 6:17 AM, Øyvind Hanssen wrote:<br></div><div> >> I have observed some cases of abuse of the APRS-IS network. It is too <br></div><div> >> easy to post disinformation or to do DOS attacks, etc. Also, everyone <br></div><div> >> can read the APRS-IS data stream. Maybe there are local APRS-IS <br></div><div> >> networks that need a more restrictive access policy?<br></div><div> >><br></div><div> >> The verification scheme is not designed to be secure. It is a simple <br></div><div> >> hash of the username (callsign). Alternatively we might use SSL/TLS <br></div><div> >> when making connections to APRS-IS nodes, but it is more complex to <br></div><div> >> handle and not all software support it. It is necessary to have a CA <br></div><div> >> that issues certificates, etc. etc. .<br></div><div> >><br></div><div> >> What about a more secure hashing scheme? Using a secret + the <br></div><div> >> username to generate a hash. HMAC (possibly with SHA-256) is a de <br></div><div> >> facto standard and more secure than a simple hashing scheme. Hashes <br></div><div> >> can be truncated and base-64 encoded. If existing software can use <br></div><div> >> e.g. a 16 character code instead of the 4-digit (16bit) passcodes <br></div><div> >> without modification, it may be something? Also, such a scheme does <br></div><div> >> not encrypt content. If that is a requirement, maybe SSL/TLS is better.<br></div><div> >><br></div><div> >> It is not a proof of identity, but is a proof that you either know <br></div><div> >> the secret or someone who does, has granted you access. Only <br></div><div> >> passcode-issuers and APRS-IS nodes need to know the secret. The risk <br></div><div> >> is of course that the secret is leaked and it may be rather <br></div><div> >> cumbersome if it must be renewed.<br></div><div> >><br></div><div> >> 73<br></div><div> >><br></div><div> >> LA7ECA, Øyvind<br></div><div> >><br></div><div> >><br></div><div> >> _______________________________________________<br></div><div> >> aprssig mailing list<br></div><div> >> <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br></div><div> >> <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br></div><div> ><br></div><div> ><br></div><div> > _______________________________________________<br></div><div> > aprssig mailing list<br></div><div> > <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br></div><div> > <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br></div><div> <br></div><div> <br></div><div> _______________________________________________<br></div><div> aprssig mailing list<br></div><div> <a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br></div><div> <a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br></div></blockquote></div><div><span>_______________________________________________</span><br></div><div><span>aprssig mailing list</span><br></div><div><span>aprssig@lists.tapr.org</span><br></div><div><span>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</span><br></div></div></blockquote></div></div><div>_______________________________________________<br></div><div>aprssig mailing list<br></div><div><a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a><br></div><div><a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br></div><div><br></div></blockquote><div><br></div></div></blockquote></div></body></html>