ECW526

v1.8.83

[Issues Fixed]

1. Enhance the gateway detection mechanism in Bridge Mode to solve the problem that captive portal clients could not correctly redirect to gateway.

2. Solve the issue that LSP can still access when Local Web Pages was disabled.

3. Fix the problem that AP goes offline when the third octet of gateway (GW) subnet mask is less than 255(e.g., GW IP 192.168.1.1, mask 255.255.254.0).

4. Fix the issue that TX Bytes and RX Bytes statistics in the disconnection log always show 0.

5. Fix AP cannot send 802.11v post-association packets properly when band steering is enabled.

v1.8.82

• Support EnGenius fast-handover algorithm 2.0

• Remove dropbear [e-mail] encryption due to security concern.

• Fix the issue that clients may get disconnected after editing ACL rules.

• Add country code for Japan.

v1.8.81

• Add support for SAMLv2 (Security Assertion Markup Language version 2) in Captive portal with Azure-AD.

• Support HTTPS-Only for local device page.

• Support WPA2-PSK[AES] + WPA-PSK[TKIP] encryption mode.

• Speed up the LED turn-off time when the user disables the LED Light function.

Appendix for v1.x.81

1. Add support for SAMLv2 in Captive portal with Azure-AD

A captive portal is a web page that users must interact with to gain network access, often seen in public Wi-Fi networks. This update introduces support for SAMLv2 (Security Assertion Markup Language version 2), a prominent protocol used for exchanging authentication and authorization data between identity providers and service providers.

(a) What is SAMLv2?

SAMLv2 is an XML-based open standard for secure exchange of authentication and authorization data. It enables Single Sign-On (SSO), allowing users to authenticate once and gain access to multiple applications without re-entering credentials. In the context of Azure AD, SAMLv2 facilitates secure communication between Azure AD (the identity provider) and various services (service providers) users want to access.

(b) Implications of This Update

• Enhanced Authentication: Users can now authenticate through Azure AD when accessing a network via a captive portal. This means that organizations leveraging Azure AD for identity management can extend its use to captive portals, ensuring a consistent and secure authentication process.

• Single Sign-On (SSO): With SAMLv2, users benefit from SSO capabilities. They log in once with their Azure AD credentials and gain seamless access to multiple services and applications without the need to re-authenticate, improving user experience and productivity.

• Increased Security: SAMLv2 enhances security by enabling strong authentication and reducing password fatigue. It ensures that authentication tokens are securely transmitted and managed, protecting user credentials from potential attacks.

(c) Practical Applications

Organizations can now implement SAMLv2-based captive portals, allowing users to connect to networks using their Azure AD credentials. This integration streamlines access management and bolsters security, making it especially beneficial for enterprises with a high reliance on Azure AD for identity services.

In summary, the support for SAMLv2 in Azure-AD captive portals facilitates a more secure, efficient, and user-friendly authentication process, aligning with modern enterprise needs for robust identity and access management.

2. Support HTTPS-Only for local device page

To address security concerns, we have introduced an HTTPS-only switch that allows users to control access to the Local Service Page (LSP). This feature is essential for enhancing the security of local device management by ensuring that all communications are encrypted.

(a) Importance of HTTPS for Security

HTTPS (Hypertext Transfer Protocol Secure) is an extension of HTTP and is widely used to secure data transmission over the internet. When enabled, HTTPS ensures that all data exchanged between the user's browser and the local device page is encrypted. This encryption is crucial for several reasons:

• Data Privacy: HTTPS uses TLS (Transport Layer Security) to encrypt the data, making it unreadable to any third party that might intercept the communication. This protects sensitive information such as login credentials and configuration settings from being exposed.

• Data Integrity: Encryption also ensures that the data transferred has not been altered during transmission. It prevents tampering and ensures that the information received by the user is exactly what the server sent.

• Authentication: HTTPS verifies the identity of the local device page, ensuring that users are connecting to the correct page and not a malicious site impersonating it. This helps prevent man-in-the-middle attacks where an attacker might intercept and alter communications between the user and the device.

• User Trust: Users are more likely to trust and engage with local device pages that employ HTTPS, as indicated by the padlock icon in the browser's address bar. This visual assurance helps build confidence in the security of the connection.

(b) Implementation and Control

By introducing an HTTPS-only switch, we empower users to enforce this level of security. Users can easily enable this switch to ensure that all access to the Local Service Page is through HTTPS. This change mitigates risks associated with unencrypted HTTP connections, such as eavesdropping and data breaches.

In summary, the HTTPS-only feature significantly enhances the security of local device pages by ensuring encrypted, authentic, and tamper-proof communication, thereby protecting user data and fostering trust.

v1.8.75

• This f/w version is for the first release.