It appears that “DNS over TLS” support is being added to Android, according to several commits added to the Android Open Source Project (AOSP). The addition in the Android repository shows that a new setting will be added under Developer Options allowing users to turn on or off DNS over TLS. Presumably, if such an option is being added to Developer Options, then that means it is in testing and may arrive in a future version of Android such as version 8.1.
By default, a DNS client desiring privacy from DNS over TLS from a particular server MUST establish a TCP connection to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over TLS.
而且建議如果另外定義的話，不要用 port 53：
This recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks.
另外也說明了在 port 853 上禁用明文傳輸：
DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages.
An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.
第三個則有可能直接爆破執行程式碼：
A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server.
We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.
// Decrypt to plaintext + mac + padding
$plaintext_mac_padding = decrypt($ciphertext);
if (NULL != $plaintext_mac_padding) {
// Now decode padding part
$plaintext_mac = decode_padding($plaintext_mac_padding, $padding_length);
if (NULL != $plaintext_mac) {
// Now check MAC part
$plaintext = check_mac(plaintext_mac);
if (NULL != $plaintext) {
// Now it's okay
}
}
}
In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC.
This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.
The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.
