[HamWAN PSDR] Encryption on HamWAN

[Steve]

The Seattle EOC even has the infrastructure for a dish for that in mind,
but as far as I know never implemented it.

Hughesnet has an entire system for doing what you said.

Steve N0FPF


On Sat, Jul 20, 2019 at 5:25 PM Mark Anderson <halpilot at comcast.net> wrote:

> Why isn’t HughsNet or ViaSat not mentioned as an an option here? I run a
> Hybrid gateway off of HughsNet with no issues and full internet access to
> the QTH when terrestrial ISP fails. If adopted by EOCs, WebEOC remains
> operational during critical terrestrial ISP outages?
>
> Sent from my iPhone
>
> > On Jul 19, 2019, at 12:54 PM, Bart Kus <me at bartk.us> wrote:
> >
> > I think it's important to recognize that the Internet has changed
> significantly since the project's inception in 2012.  Two very important
> things came to pass, that impact the HamWAN use case arguments in 2012:
> >
> > 1) HTTPS became universally deployed, instead of being reserved for
> specific pages.
> > 2) Browsers have removed support for null-cipher HTTPS.
> >
> > Even the use case of surfing Wikipedia can't be done on HamWAN these
> days.  Heck, you can't even do a Google search for anything.
> >
> > Is there a point to powering a network that's so useless?  As Thom
> points out, it can't even be used for WebEOC emcomm either.  People need to
> regularly test + practice emcomm tools for them to be usable in a real
> emergency.  This is not allowed right now.
> >
> > Part97 is incompatible with modern computing life, and we might be
> better off having a smaller footprint that offers actual utility.
> >
> > Or we can just wait a couple years for StarLink / OneWeb.
> >
> > --Bart
> >
> >
> >> On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote:
> >> Thom,
> >>
> >> This is something we’ve thought about as well. The FCC is explicitly
> permissive in the case of a real emergency, though that doesn’t really
> cover the use case during the rest of the time. This is one of a number of
> reasons why we (the network admins) have specifically avoided blocking
> anything but blatant abuse (mostly virus type stuff). We want to leave the
> possibility open in terms of the network for these sorts of cases, but that
> comes with users needing to take on the responsibility to maintain their
> own compliance.
> >>
> >> The team is discussing ways we can help with this, while leaving things
> as flexible as possible. One of the current front running ideas is adding
> instructions to the client node configuration page that everyone uses to
> set up their modems, to block HTTPS at your modem. That leaves you the
> option to disable it if required (unlike if we implemented the block on the
> network side), but helps to maintain compliance during regular activities.
> It’s still very much an active discussion at this point, but if folks have
> ideas we’ll certainly welcome them.
> >>
> >> Thanks,
> >> Nigel
> >>
> >>> On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott at gmail.com>
> wrote:
> >>>
> >>> Nigel,
> >>>
> >>> Thanks for the reminder, I'm not one to argue that, but it does bring
> up a question.  There is not much of the web left that is not HTTPS, I'm
> thinking particularly of emergency management sites such  as WebEOC. Is
> this violation likely to be excused when providing communications support
> in a real public emergency?
> >>>
> >>> Thanks,
> >>>
> >>> Thom Wescott
> >>> KI7EFG
> >>> _______________________________________________
> >>> PSDR mailing list
> >>> PSDR at hamwan.org
> >>> http://mail.hamwan.net/mailman/listinfo/psdr
> >> _______________________________________________
> >> PSDR mailing list
> >> PSDR at hamwan.org
> >> http://mail.hamwan.net/mailman/listinfo/psdr
> >
> > _______________________________________________
> > PSDR mailing list
> > PSDR at hamwan.org
> > http://mail.hamwan.net/mailman/listinfo/psdr
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>
-- 
Pardon the brevity, sent from a mobile device. So there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20190720/e285a4ca/attachment.html>