Improve IPv6 support and system DNS servers discovery #236
Conversation
Fix the issue because of which there was no hostname verification during the TLS handshake. refactor(dns-windows): improve DNS server discovery Filter out DNS servers received from disconnected adapters, loopback, and APIPA addresses. test(dns-tls-windows): add test to test DNS discovery Added tests to test DNS server discovery in a controlled Windows environment (manual).
…hen gateway info is unavailable.
Refactor code to identify the currently used adapter and retrieve list of DNS servers that are reachable from it.
Co-authored-by: Mateusz Dahlke <[email protected]>
Added SNI (Server Name Indication) support for TLS connections. feat(ssl): add hostname verification Added hostname verification for SSL/TLS certificates to prevent MITM attacks.
Update bundled certificates which is used for secured connection and peers verification.
Add the Let's Encrypt ISRG Root X1 Certificate for Windows and parametrically for other platforms.
Add working IPv6 route detection to decide the preferable connection interface. refactor(dns-server): try user-provided IPv6 DNS servers first When built with IPv6 support, first try to use any of the user-provided IPv6 DNS servers before falling back to the user-provided IPv4 before falling back to the address provided by a well-known DNS provider. refactor(dns): request `A` and `AAAA` DNS records for domain When built with IPv6 support, SDK will send two queries to receive both records and decide which will be most suitable for currently available routing.
parfeon
added
status: done
Fix issue because of which `pubnub_await` wasn't waiting after `pubnub_cancel` has been called. fix(proxy-windows): fix auto-detection PAC proxy Fix `WinHttpGetProxyForUrl` usage with URL with schema instead of domain only. fix(dns-posix): fix `resolv.conf` parsing Fix issue with `/etc/resolv.conf` parsing where untrimmed string produced wrong address.
Some Windows-related interfaces, because of different `pubnub_` struct layouts caused by different `pubnub_config.h` type aliases and pre-processing macros, accessed and modified wrong fields. feat(pac-windows): add IPv6 support for automated proxy discovery Add handling of the IPv6 proxy address provided by automated (or PAC) proxy discovery API. fix(pac-windows): fix cached PAC result handling on Windows Fix `set_from_url4proxy` for proper `lpszProxy` parsing. refactor(config): add missing pre-processing macro for all `pubnub_config.h` Add defaults for `PUBNUB_ADVANCED_KEEP_ALIVE` in all related `pubnub_config.h` files.
KGronek-Pubnub
left a comment
KGronek-Pubnub
left a comment
There was a problem hiding this comment.
LGTM, compiled and tested on Windows (but without IPv6 support).
Xavrax
left a comment
Xavrax
left a comment
There was a problem hiding this comment.
few questions, a lot of code to be checked tbh :kekw:
LGTM but I ask for some manual testing - especially on windows machine.
| char url_for_proxy[256]; | ||
| wchar_t wide_origin[256]; |
There was a problem hiding this comment.
Are we sure for that 256 bytes will be enough? I see that e.g. web browsers allow to have much longer ones. I know that less configuration flags is always better but question is if the 256 is enough.
There was a problem hiding this comment.
This is domains, which will come from PubNub (custom user domains) and will be used in query to PAC that it will give us target proxy address to use for the connection to access that origin.
Here is how long it looks like (if we subtract 8 chars for https://):
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc.dddddddddddddddddddddddddddddddddddddddddddd.pubnubapi.com
I don't think that we ever will generate that long origin, but can adjust sizes if required ;)
There was a problem hiding this comment.
Sure thing. I know that it looks weird, but just asked as I've checked the support in other places ;d.
There was a problem hiding this comment.
FQDN is limited to 255 octets... I reduced actual length a bit to fit schema into it, but I don't think PubNub will issue that long subdomain ever to anyone :)
|
@pubnub-release-bot release |
|
🚀 Release successfully completed 🚀 |
4 participants
feat(ipv6): add IPv6 route detection
Add working IPv6 route detection to decide the preferable connection interface.
feat(dns-server): add stalled interface detection with DNS probe
When built with
PUBNUB_DNS_SERVERS_VALIDATION_TIMEOUTset to delay in milliseconds, system DNS servers' discovery will make an actual DNS query, and the value will be used as a request timeout.feat(pac-windows): add IPv6 support for automated proxy discovery
Add handling of the IPv6 proxy address provided by automated (or PAC) proxy discovery API.
fix(await): fix
pubnub_awaitafterpubnub_cancelFix issue because of which
pubnub_awaitwasn't waiting afterpubnub_cancelhas been called.fix(proxy-windows): fix auto-detection PAC proxy
Fix
WinHttpGetProxyForUrlusage with URL with schema instead of domain only.fix(dns-posix): fix
resolv.confparsingFix issue with
/etc/resolv.confparsing where untrimmed string produced wrong address.fix(memory): fix layout of
pubnub_structSome Windows-related interfaces, because of different
pubnub_struct layouts caused by differentpubnub_config.htype aliases and pre-processing macros, accessed and modified wrong fields.fix(pac-windows): fix cached PAC result handling on Windows
Fix
set_from_url4proxyfor properlpszProxyparsing.refactor(config): add missing pre-processing macro for all
pubnub_config.hAdd defaults for
PUBNUB_ADVANCED_KEEP_ALIVEin all relatedpubnub_config.hfiles.refactor(dns-server): try user-provided IPv6 DNS servers first
When built with IPv6 support, first try to use any of the user-provided IPv6 DNS servers before falling back to the user-provided IPv4 before falling back to the address provided by a well-known DNS provider.
refactor(dns): request
AandAAAADNS records for domainWhen built with IPv6 support, SDK will send two queries to receive both records and decide which will be most suitable for currently available routing.