[HamWAN PSDR] Newbie

Tue Mar 16 14:22:56 PDT 2021

As is so often happens, a public dictionary definition is not always correct.  It is well understood in the information security industry that I work in, and in military usage, to always mean prevention of unauthorized access/discovery of information.

Hashing, CRC, etc, processes used for insuring information *integrity* are NOT encryption…because they are one-way, ie the intent is not for anyone to decode the information regardless of whether they are “authorized” users or not.  Hash algorithms are typically used for verifying a message/file has not been corrupted in transit or otherwise changed, or for hiding a password (but one that cannot be decoded from the hash, ie there is no recipient key to do that).  This only matters for this HamWAN case in that CRC checksums and any Hash values are communicated in an unencrypted manner, used by system components to insure integrity of data packets and perhaps entire email messages (not sure about that one), so the “encryption” prevention of Part 97 does not apply to that.  Encryption algorithms such as SSL is not used to insure integrity, as even an encrypted message/packet can become corrupted, or changed by a man-in-the-middle attack such that it loses integrity.

Stephen W9SK

From: PSDR <psdr-bounces at hamwan.org> On Behalf Of Cory (NQ1E)
Sent: Tuesday, March 16, 2021 1:45 PM
To: Puget Sound Data Ring <psdr at hamwan.org>
Subject: Re: [HamWAN PSDR] Newbie

>  “encryption” means purposefully hiding/obfuscating/coding information with intent of unauthorized users to discover/decode the information. [...] encryption by definition is used to keep information private

You're close, but it's more nuanced than that.  The actual dictionary definition of encryption is: 

"the process of converting information or data into a code, especially to prevent unauthorized access."

They way most cryptographic protocols prevent "unauthorized access" is by using three major features, and they're not all always required:

1. Privacy - Using a cipher to encode a message in a way that hides its true meaning

2. Authentication - Verifying that the message was sent from the intended party

3. Integrity - Verifying that the message is complete and has not been altered in transit

You may be surprised to hear that the word "encryption" is not actually used anywhere in part 97.  What it actually says is:

"No amateur station shall transmit [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein" - §97.113(4)

There is nothing prohibiting us from using the non-privacy related features of cryptography in regular transmissions.  While not common, disabling ciphers is possible in SSL, SSH, and other internet protocols.  Even the IPSec tunnels HamWAN uses are part97 compliant since you can absolutely see the original traffic encapsulated in the tunnel, even though you cannot alter or impersonate it without the proper keys.

On Tue, Mar 16, 2021 at 12:35 PM Stephen Kangas <stephen at kangas.com <mailto:stephen at kangas.com> > wrote:

Let’s keep in mind that “encryption” means purposefully hiding/obfuscating/coding information with intent of unauthorized users to discover/decode the information.  To accomplish encryption, both a cipher and a key are needed; the cipher is an algorithm-driven means to hiding the information and the key is used to perform the encryption and decryption.  Symmetric encryption uses a single key shared between authorized users, whereas asymmetric encryption typically uses mathematically related key pairs…it is the latter that is done with TLS/SSL via the Public Key Infrastructure.  Regardless of how it is done, encryption by definition is used to keep information private to those who do not know the cipher or have the correct key, which is not legal in Part 97 for any purpose as I read it, whether for authentication, integrity, or confidentiality of communications.

As we hams know, there are methods of “coding” information that may seem like purposeful encryption, but are not because the ciphers and keys are publicly, even widely, available to anyone.  Examples include Morse Code, CRC checksums (for integrity), IPA, digital communications protocols OTA, etc.  These are not encryption (contrary to how some old hams argue who do not understand PSK31 or other “new” digital protocols for example).  So the question pertaining to what we’re discussing is: is the intent to purposely make the data private for some by a few or even a group of only those people (or machines/programs) who know the cipher used and have the key to decode?  Apparently the connection from default installation of Winlink Express for Windows to CMS does intend to keep that traffic private using a method very difficult to break encryption for most public observers (at least when local RMS is performed during the install).  

Stephen W9SK

From: PSDR <psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org> > On Behalf Of Aaron Taggert
Sent: Tuesday, March 16, 2021 8:27 AM
To: Puget Sound Data Ring <psdr at hamwan.org <mailto:psdr at hamwan.org> >
Subject: Re: [HamWAN PSDR] Newbie

On the authentication/integrity side... FCC says no encryption so we can all hear what you're on about. Ham would not be much fun if all you heard was encrypted pseudo noise. SSL/TLS authentication is a bit like me sending you a list of 100 words and asking you to tell me word 45. Everything is in the clear, but I can authenticate that whomever is at the other end at least has the right list. Another SSL/TLS feature is integrity, meaning the whole message is received. They would be like saying I sent 3421 characters CW 786 of them were vowels. Again everybody can hear what we're saying but it would be difficult to impersonate the sender (or receiver) or change the message.

On Tue, Mar 16, 2021, 6:32 AM Steve - WA7PTM <psdr-list at aberle.net <mailto:psdr-list at aberle.net> > wrote:

If we separate Winlink (the system) from Winlink Express (the client 
program), is a SSL connection also the case with the other six clients 
listed on the https://winlink.org/ClientSoftware page when used in 
telnet mode?

Steve

Scott Currie wrote on 3/15/21 10:06 PM:
> Yeah, I discussed this with the WDT, and the issue with using HamWAN or
> ARDEN. I had asked if we could force a non-SSL connection to the CMS. They
> have been under pressure from AWS to switch to all SSL connections, so they
> had to make the change. They did commit to leaving the client or gateway
> connection to RMS Relay as non-SSL, so that is why we have suggested having
> a regional instance of RMS Relay on HamWAN that the RMS Gateways and
> clients could point to. Backend of the RMS Relay would then connect to the
> CMS over SSL on a hardened Internet connection (like at a county EOC or the
> State EOC), or even HF forwarding if the Internet is down.
> 
> -Scott
> 
> On Mon, Mar 15, 2021 at 9:41 PM Stephen Kangas <stephen at kangas.com <mailto:stephen at kangas.com> > wrote:
> 
>> Scott, thanks for that update, interesting.  “Telnet” is a misnomer in
>> this WinLink instance, as that port 22 protocol is historically and
>> normally unencrypted, and widely understood in the industry as such
>> (whereas SSH is encrypted).   It looks like the email client is connecting
>> locally to an RMS Relay in that mode, which then connects to the CMS on the
>> internet.
>>
>>
>>
>> --Stephen W9SK
>>
>>
>>
>> *From:* PSDR <psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org> > *On Behalf Of *Scott Currie
>> *Sent:* Monday, March 15, 2021 5:56 PM
>> *To:* Puget Sound Data Ring <psdr at hamwan.org <mailto:psdr at hamwan.org> >
>> *Subject:* Re: [HamWAN PSDR] Newbie
>>
>>
>>
>> This is not entirely true. Winlink does use TLS/SSL connections for some
>> things. The normal telnet connection is now SSL (will fallback to non-SSL
>> if the connection fails). Also, RMS Gateway to the CMS is now SSL. Telnet
>> P2P and telnet to RMS Relay is not SSL. I believe updates are also SSL now.
>>
>>
>>
>> Winlink Express Link Test:
>>
>> Test started 2021/03/16 00:52 UTC
>>
>> Testing CMS telnet connection to cms.winlink.org <http://cms.winlink.org>  through port 8772...
>>    Successfully connected to a CMS through port 8772 in 253 Milliseconds
>>
>> Testing CMS SSL telnet connection to cms.winlink.org <http://cms.winlink.org>  through port 8773...
>>    Successfully connected to a CMS through port 8773 in 311 Milliseconds
>>
>> Testing API service access through port 443 to api.winlink.org...
>>    Successfully performed API service to api.winlink.org <http://api.winlink.org>  through port 443
>> in 756 Milliseconds
>>
>> Testing Autoupdate server access through port 443 to
>> autoupdate2.winlink.org...
>>    Successfully checked autoupdate server through port 443 in 439
>> Milliseconds
>>
>> Testing connection to web site - www.winlink.org:443 <http://www.winlink.org:443> 
>>    Successfully connected to www.winlink.org <http://www.winlink.org>  through port 443 in 47
>> Milliseconds
>>
>> Testing FTP connection to SFI site -
>> ftp://ftp.swpc.noaa.gov/pub/latest/SGAS.txt
>>    Successfully connected to ftp://ftp.swpc.noaa.gov/pub/latest/SGAS.txt
>> through port 20/21 in 1522 Milliseconds
>>
>> Test completed successfully.
>>
>> -Scott, NS7C
>>
>>
>>
>> On Mon, Mar 15, 2021 at 5:45 PM Stephen Kangas <stephen at kangas.com <mailto:stephen at kangas.com> > wrote:
>>
>> Phil, an example of the ham band traffic that Kenny mentioned is not
>> permitted by the FCC is encrypted communications traffic…this means the
>> majority of websites your visit today and many email hosters, since
>> websites commonly use TLS/SSL encryption (indicated by “https” in front of
>> the URL in your browser address bar) or encrypted settings in your email
>> hoster & client.  Winlink does NOT use encryption, thus is legal, and is
>> the primary application for my ARES team using HamWAN.  As Kenny points
>> out, certain routers (not inexpensive home models) can be used to split
>> that traffic appropriately, but it is not an easy setup unless you have a
>> background in data networks or cybersecurity…so it’s far easier to either
>> use HamWAN just for your dedicated ARES laptop use or switch a cable back
>> and forth using one pipe at a time.
>>
>>
>>
>> FWIW, Stephen W9SK
>>
>>
>>
>>
>>
>> *From:* PSDR <psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org> > *On Behalf Of *Kenny Richards
>> *Sent:* Monday, March 15, 2021 12:49 PM
>> *To:* Puget Sound Data Ring <psdr at hamwan.org <mailto:psdr at hamwan.org> >
>> *Subject:* Re: [HamWAN PSDR] Newbie
>>
>>
>>
>> Just want to add two things to what Carl said already.
>>
>>
>>
>> 1) Line of sight means you can actually 'see' the HamWAN node, or at least
>> you can with something like a pair of binoculars.
>>
>>
>>
>> 2) Remember that HamWAN is not meant to be a replacement for your home
>> internet. Be very conscious of what traffic you are putting over HamWAN. I
>> don't recommend connecting it to your home network unless you are familiar
>> enough with routing rules to limit what traffic goes out the HamWAN link.
>>
>>
>>
>> Good luck,
>>
>> Kenny, KU7M
>>
>>
>>
>>
>>
>> On Mon, Mar 15, 2021 at 12:40 PM <carl at n7kuw.com <mailto:carl at n7kuw.com> > wrote:
>>
>> Hi Phil,
>>
>> You can do all of the configuration while on the ground, but obviously you
>> won’t have any signal. You don’t indicate what specific equipment you have,
>> but if you have the mAnt30 dish and separate router/modem, make sure you
>> have the antenna connected before powering it up.
>>
>>
>>
>> As to trees, they are an absolute show stopper. You must have clear,
>> visual, line of sight to the HamWAN site you are shooting to. Hopefully you
>> will have that, or can achieve that, from where you plan to mount the
>> dish.  As to “just over them”, a microwave shot consists of the direct,
>> pure line of sight, but also what is referred to as the Fresnel zone – a
>> cigar shaped “balloon” around the pure line of sight.  Items in the Fresnel
>> zone (including trees) can reduce the amount of signal you have, so you may
>> not get optimum performance, but some.
>>
>>
>>
>> In your initial post you commented about how to balance between your
>> regular internet and HamWAN for a Winlink node.  My suggestion would be to
>> just leave it on one (whichever one) as the norm, and only switch to the
>> other if the one goes down.  You can also acquire routers that include
>> failover capability to automatically make that switch.  You can go more
>> advanced with load sharing and such between multiple connections, but that
>> requires much better understanding of internet routing, and for a winlink
>> node basic failover will serve your purpose.
>>
>>
>>
>> Good luck, let us know how things turn out.
>>
>> Carl, N7KUW
>>
>>
>>
>> *From:* PSDR <psdr-bounces at hamwan.org <mailto:psdr-bounces at hamwan.org> > *On Behalf Of *Phil Cornell via
>> PSDR
>> *Sent:* Monday, March 15, 2021 12:11 PM
>> *To:* psdr at hamwan.org <mailto:psdr at hamwan.org> 
>> *Subject:* [HamWAN PSDR] Newbie
>>
>>
>>
>> OK, I figured out my problem and I now have Winbox talking to the radio
>> and reporting status.  I's not linking to anything since the antenna is
>> still on the ground.  How much configuration can I do before mounting it on
>> my roof.  The only question in my sight path may be some trees but I think
>> I can aim just over them and get a signal.  My friend Bruce/WA7BAM will be
>> helping with the antenna installation on Wed afternoon.  Making progress...
>>
>>
>>
>> *Phil Cornell  *
>>
>> *W7PLC *
>>
>> *SHARES NCS590*
>>
>> *Hybrid Gateway W7PLC*
>>
>> *TCARES  VP*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org> 
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org> 
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
>>
>>
>>
>> --
>>
>> *-Scott*
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org> 
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
> 
> 
> 
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org <mailto:PSDR at hamwan.org> 
> http://mail.hamwan.net/mailman/listinfo/psdr
> 
_______________________________________________
PSDR mailing list
PSDR at hamwan.org <mailto:PSDR at hamwan.org> 
http://mail.hamwan.net/mailman/listinfo/psdr

_______________________________________________
PSDR mailing list
PSDR at hamwan.org <mailto:PSDR at hamwan.org> 
http://mail.hamwan.net/mailman/listinfo/psdr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20210316/9a632244/attachment.html>