BloodBlade I don't know what you want to argue about, but I still hold the view that a more secure connection method requires someone to actively promote it. As long as the number of people using five-digit passcodes continues to increase, the proposal will remain ineffective. I may have misunderstood; the widespread adoption of HTTPS is the result of multiple parties working together, and it occurred after a large number of people realized that HTTP without encryption was insecure and became a common consensus among website owners. This is just one example.
Similar situations include: any national standard that starts with "GB" is a mandatory standard, but even mandatory standards are entirely based on personal preference. "GB/T" standards are recommendations and can be followed or not. For example, GB/T 20234.3-2023, which specifies the connection device for electric vehicle conductive charging – Part 3: DC charging interface, is a standard used for fast charging of domestic electric vehicles. However, this standard itself is not mandatory, but because enterprises and the public recognize it, it has effectively become a standard that everyone follows, even in Russia.
There's one thing I've made perfectly clear: no one is pushing this, and it hasn't become a consensus. Even the best and safest proposals can only sit around and do nothing. Most APRS-IS users will still use passcode verification or continue to use calculators, regardless of when a particular feature is completed or what my opinion may be.
The question arises: why did you say that?This functionality has been in use for many years, and yet people are still using Passcode?I haven't found any APRS-related tutorials that mention certification, so I'm wondering why it's not used by the target audience.
After a long period of development, the certificate authentication feature remains experimental and the number of supported SSL servers is decreasing.
The following excerpt is from DeepSeek:
- 📌 Important Current Status and Precautions:
- Experimental Feature: It's important to note that this is currently an experimental feature. Not all APRS-IS servers support it, and it is primarily supported by a few aprs2.net servers.
- Limited support: Currently, this feature primarily accepts certificates issued by ARRL LoTW.
- Service Availability: According to recent user reports, the number of `ssl.aprs2.net` servers supporting this feature appears to have decreased, and connection failures may be caused by issues such as expired server certificates.
- Encryption considerations: To comply with relevant regulations for amateur radio, some implementations may use NULL encryption (which does not actually encrypt data), which could lead to compatibility issues with certain clients.
So, the problem now is quite simple: the certificate authentication functionality is not mature at all, which explains why no one recommends it.
闽ICP备2021006864号-7
闽公网安备35020602002794号