HTTPS & Non-HTTPS security

[d.walenczak]

Hey guys,

I was giving some thought to security (as I'm occasionally wont to do😂). While fixing the injection vulnerabilities goes a long way, I think there are a couple of areas where we can offer improved security to users. Specifically, two areas come to mind:

Password/Login Security

I'm running my instance on my local network with no HTTP. And yes, HTTPS is the gold standard for web servers to implement for security. But I can imagine that some people may not be familiar with adding TLS to their web servers. My gut is to say "Well, that's a them problem"... which it may be. But doesn't mean we can't take some meaningful steps to offer some protection. And I realize what I'm about to propose is essentially rolling our own non-HTTPS HTTPS. But I was thinking that perhaps we could implement a public/private encryption on the login form. Default PHP implementations do come with the open_ssl extension shipped and enabled. Perhaps we have it generate a public and private key at the end of the installation phase. In PHP, we could detect if the login page is being requested via non-HTTPS means. If so, we could enable the JavaScript that would encrypt the username/password sent over unencrypted HTTP traffic using the generated public key (plus maybe a one-time pad or timestamp) so that only the server can decrypt it. This will protect users (especially those with internet-exposed instances) from having their passwords jacked by being sent in the clear. Again, totally get that people should use HTTPS, but I think we should still include an intrinsically safe fallback by default. And, I would suggest that anything to do with "patient" PHI/PII have the same protection. I imagine most people who would use TicketsCAD aren't "covered entities" in terms of HIPAA compliance (though some might be), I don't think that alleviates one's ethical responsibilities as an organization (or, even as software devs/maintainers) from ensuring that all necessary and proper steps are taken to safeguard this nonetheless. Rolling our own TLS isn't optimal (HTTPS is), but it may be a necessary fallback when unskilled users implement TicketsCAD without HTTPS. We should make it "safe out of the box". Heck, at that point, it probably won't be a big deal to roll it into any form submitting page to make all submissions secure and private (after all, the work would already be done). We should just make sure there's a backend settings flag to turn it off so that I don't have the use more advanced tools to debug form submission traffic.

HTTPS-ready structure

I haven't tested our code to see if we're able to take advantage of HTTPS. While most of it is transparent to the underlying code, there are two things I can think of:

1. Linking downstream URLs using the same security scheme. If a page is requested via HTTPS, our links should start with https:// (assuming we're including those at all). Yes, a properly configured webserver should be set to redirect HTTP to HTTPS. This doesn't change that this is an active configuration step that someone may omit either by accident or by lack of knowledge. This would prevent an accidental leak of information via an unintentional HTTP downgrade -- going back to the "secure out of the box" philosophy.
2. Using secure websockets. I believe the library we are incloding for WebSockets does support switching to secure WebSockets, but seeing that we hardcode the ws:// prefix, I think this disables this capability. We may want to see if this is something we should tweak. Similarly, we should consider an icon, indicator, or warning text letting chat users know that their session is unencrypted.

I wanted to get your input on whether you think this is a direction we should go down or  an avenue we should pursue, or whether we should just chalk it up (for the first item, at least) to user responsibility. I like the concept of secure out of the box, even if not properly set up to use https, and I'm not opposed to putting in the work to, essentially, reinvent the TLS wheel here. But I wanted to get some guidance on direction to see if this is something I should even work on in the first place.

[Eric Osterberg]

There are some implications of having encryption to amatuer rado. Unfortunately encryption is prohibited.

AI Generated answer:

The key regulation is:

👉 47 CFR §97.113(a)(4)

• Amateur stations may NOT transmit:

  “messages encoded for the purpose of obscuring their meaning”

🔑 What that means in plain English

• You cannot intentionally hide the meaning of a transmission
• This effectively bans:
  • Encryption (AES, TLS, etc.)
  • Voice scrambling
  • Secret codes or ciphers

Even though the word “encryption” isn’t explicitly used in the rules, this clause is universally interpreted as a prohibition on encryption.

---

🚫 What is NOT allowed

Under FCC rules, the following are not permitted on amateur frequencies:

❌ Encryption / secrecy

• AES, RSA, TLS, VPN tunnels
• Encrypted mesh networks (e.g., Meshtastic with encryption enabled)
• Encrypted digital voice streams

❌ Intentional obfuscation

• Custom ciphers or “secret language”
• Voice inversion/scrambling
• Any method designed so others cannot understand the content

👉 The intent matters: if your goal is to hide meaning, it’s illegal.

---

✅ What IS allowed (important nuance)

The FCC does allow certain things that may look like encryption but are not intended to obscure meaning:

✔️ Encoding (not secrecy)

• Morse code (CW)
• Digital modes (FT8, PSK31, APRS)
• Compression or modulation schemes

👉 These are fine because they are:

• Publicly decodable
• Not intended to hide meaning

---

✔️ Error correction / compression

• FEC (forward error correction)
• Data compression

👉 Allowed as long as the message can be decoded by others using standard methods.

---

✔️ Authentication / signatures (gray area but generally accepted)

• Message signing (not encryption)
• Hashes for integrity

👉 Allowed if:

• The message itself remains readable
• You’re not hiding content

------------------------------------------------

And on to your other points.

I will add these to the roadmap. Likely for Tickets v4.0.0

The idea of RSA-encrypting form fields over HTTP is architecturally sound but comes with caveats:

• It protects against passive network sniffing (someone watching traffic)
• It does NOT protect against active MITM attacks (an attacker could replace the public key in the HTML)
• The Web Crypto API is the right tool (not a JS RSA library)
• A timestamp or nonce prevents replay attacks
• I'd implement it — but with a permanent, prominent banner: "⚠️ This connection is not encrypted. Configure HTTPS for full security."

data at rest encryption:

• PHI/PII encryption in the database is the most complex and has performance implications (encrypted columns can't be indexed or searched)
• I'd tag the columns first (metadata), then encrypt selectively — patient names and medical info, but NOT addresses (needed for geocoding)

--
You received this message because you are subscribed to the Google Groups "Open Source CAD - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-source-cad-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-source-cad---dev/f73cb06f-d8e6-4af7-b411-6f33cf360873n%40googlegroups.com.

[Dominick Walenczak]

Hey Eric,

AI was off the mark on this one, I'm afraid. Encryption was strictly in the context of web traffic (web logins, PHI/PII, WebSockets). Not related to radios at all. Unless we're talking about transmitting the TicketsCAD website via 44Net/AMPRNet./HamWAN/AREDN. In which case, it's technically correct... but probably not really ever a use case for TicketsCAD (I could be wrong, of course).

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad---dev/CAJLaYFVej%2BNZ1Q0emGPJ5ndbfHiMKabQUS4HFUUDK2r6mq0RFA%40mail.gmail.com.

[Eric Osterberg]

The concern about enforcing encryption was my own as I have used ham mesh for tickets access.

I think it's important that we support the idea that encryption must be disabled for certain use cases. 

I agree that secure by default is an important principle, but in the context of tickets CAD, we need to provide some flexibility.

To view this discussion visit https://groups.google.com/d/msgid/open-source-cad---dev/CAPiTh_jDcztq3VQWkzCWyzv%2By_49%2BJOaFGo6KiC15Dq7KGHCzw%40mail.gmail.com.