Possible interop problems with other DoH servers. #59
Comments
|
@complex2d Thanks for the detailed report! It may take a few days due to the holidays but we will investigate this. cc @jwijenbergh for visibility as well. |
|
@weyrick Thanks for the visibility. where cert.pem and key.pem are self signed using openssl. This ends up with a correct query and response. And also the headers that are being send with flamethrower seem to be correct I had a feeling that the url parsing library that we use might be faulty when an ip is supplied, this does not seem to be the case. @complex2d diff --git a/flame/httpssession.cpp b/flame/httpssession.cpp
index 1a9b98a..3e4f06d 100644
--- a/flame/httpssession.cpp
+++ b/flame/httpssession.cpp
@@ -54,6 +54,9 @@ std::unique_ptr<http2_stream_data> HTTPSSession::create_http2_stream_data(std::u
path.append("?dns=");
path.append(data.get(), len);
}
+ std::cout << "PATH: " << path << std::endl;
+ std::cout << "SCHEME: " << scheme << std::endl;
+ std::cout << "AUTHORITY: " << authority << std::endl;
std::string streamData(data.get(), len);
auto root = std::make_unique<http2_stream_data>(scheme, authority, path, stream_id, streamData);
return root;This is to verify if the headers are actually sent correctly (which as you stated they probably aren't). Hopefully I will get some more helpful information to help debug this. |
|
I'm on holiday right now, but I will do this as soon as I possibly can and get back to you. If it's at all helpful, the version I was using was the one pulled from the public docker image, rather than one I built myself. I will try building from source with the additional prints above asap. |
|
I built from source with the logging requested, and it works fine now... I feared that might be the case: To Apache: (Apache log omitted because it's fine) To doh-proxy: output from doh-proxy: Given that, I suspect the issue might be with the public docker image. I can revert right back to the strange non-working behavior if I return to using the docker image rather than the version I just built from source. I'm fairly confident my docker environment is fine, because I can run ns1labs/flame without issue, and it works great for standard DNS, just not DoH. |
|
Interesting, I will investigate the public docker image to see if I can find a problem with the build. Thanks again for the report. |
|
@complex2d can you let me know what versions of libraries you built with locally, especially nghttp2? |
root@planck2:/etc/apache2/sites-enabled# dpkg -l | grep nghttp; dpkg -l | grep cmake; dpkg -l | grep libuv; dpkg -l | grep libldns; dpkg -l | grep gnutls; dpkg -l | grep g++; If you see anything missing there, let me know. As a side note, I've been meaning to spend more time with this and look into some other issues, but I've been absolutely slammed with work lately. I may be a bit slow to respond. |
|
There is a possibility that this MR has solved at least some of the interoperability problems: |
|
A few years late, but wanted to circle back around and mention that I've largely left the industry. I doubt I'll be able to help out with any testing from here on out. If you believe this is resolved, please feel free to close it. |
I've made a couple of attempts to get Flamethrower working against DoH servers in a test harness environment running Ubuntu 20.04.1 LTS, and so far I'm not having any luck.
My first attempt was to deploy Apache 2.4.41 as the HTTP/2 service handler/muxer and DoH Server desribed here: https://github.com/m13253/dns-over-https
The only major differences in my deplpyment are the DoH server and Apache are not on the same box (mostly for tcpdump and troubleshooting reasons), and the fact I'm not using OSCP stapling or a real CA signed cert, which as far as I know should be perfectly fine for an isolated test harness.
My Apache 2.4.41 config is very simple, and just terminates the H2 connection and proxies the query to the DoH server:
When I use a DoH test client such as the doh-client that comes with facebookexperimental's doh-proxy (https://github.com/facebookexperimental/doh-proxy), it works just fine, as shown here:
Apache ssl_access.log:
10.10.20.20 - - [23/Dec/2020:11:35:53 -0800] "GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwRkb2gxA2NvbQAAAQAB HTTP/2.0" 200 587 "-" "-"However when I try to run Flamethrower with extremely light serial queries pointed at the Apache server, Apache rejects the HTTP/2. It appears it does not like something about the HEADERS frame, but I'm not entirely sure what:
Apache error log:
Apache really doesn't like something about the HTTP/2, claiming it received an invalid frame.
My final attempt was to give up on Apache and just spin up the facebookexperimental doh-proxy, but pointing Flamethrower to that also fails.
Launching doh-proxy:
NOTE: doh-proxy was slightly modified to print out the headers so I could see what doh-proxy was getting from the Flamethrower client.
Running Flamethrower:
Output from doh-proxy (printing the headers list):
As you can see above, Flamethrower is claiming it's getting back malformed data which could be true, but it also looks like the headers being sent by Flamethrower might be an issue. The path header is supposed to contain the complete URI, including the /dns-query part, but it's missing for some reason. Scheme and authority should probably also be set. Any ideas why this might be the case?
Am I doing something wrong here in how I'm executing Flamethrower from Docker? Any help/guidance would be super cool.
Thanks in advance, and happy holidays! :)
The text was updated successfully, but these errors were encountered: