maoertel / diqwest

Crate to extend `reqwest` to be able to send with digest auth flow.
https://docs.rs/diqwest
MIT License
18 stars 3 forks source link

Issue with Mikrotik SwOS #10

Closed daniel-widrick closed 1 year ago

daniel-widrick commented 1 year ago

I'm working on a program to log into the web interface of a Mikrotik Switch.

The authentication is failing with diqwest. The authentication works as expected in a browser / with curl.

I created a VERY simple program(golang) to act as an http server and ALWAYS send the same WWW-Authenticate Header:

package main

import "net/http"

func main() {
    http.HandleFunc("/hello", getHelo)
    err := http.ListenAndServe(":8099", nil)
    if err != nil {
        println(err.Error())
    }
}

func getHelo(w http.ResponseWriter, r *http.Request) {
    println(r.Header.Get("Authorization"))
    w.Header().Set("WWW-Authenticate", "Digest realm=\"CSR305-1G-4s+\", qop=\"auth\", nonce=\"7f267bd4\", stale=FALSE")
    w.WriteHeader(401)
    w.Write([]byte("Hello"))
}

The Curl Test command: curl -vvv --digest -u "admin:admin" http://127.0.0.1:8099/hello

and the Rust diqwest code:

    let client = Client::new();
    let url = format!("http://{}/hello","127.0.0.1:8099");
    let mut response = client
        .get(&url)
        .send_with_digest_auth("admin", "admin");

Below are the headers received by the server:

cURL :: Digest username="admin", realm="CSR305-1G-4s+", nonce="7f267bd4", uri="/hello", cnonce="ODRkZjFjYWQ4NDQwYmM0NmFjM2JjMjg0NDU1YmJlYmQ=", nc=00000001, qop=auth, response="9b919621bc520ba65b54b9ae73039d17"

Diqwest :: Digest username="admin", realm="CSR305-1G-4s+", nonce="7f267bd4", uri="/hello", cnonce="9e6a40050bb3da09b2c172af433d7c90", nc=00000001, qop=auth, response="2c1604f23e48d28111d47e33b81a3d13", algorithm=MD5

qop is auth and the algorithm is unspecified.

HA1 should be: 903fda724aba1586c086fdbed1e7eeb0 HA2 should be: 87969d867ee02588e3220f2c3b0ad34b

cURL's response should be: 9b919621bc520ba65b54b9ae73039d17 diqwest's response should be: 2c1604f23e48d28111d47e33b81a3d13


is it possible that the additional "algorithm=MD5" header is messing up the auth algorithm in SwitchOS?

daniel-widrick commented 1 year ago

Despite the RFC saying that if the algorithm is unspecified it's ASSUMED to be md5... The quoted section below MAY suggest it's a bug for the algorithm to be included when not specified by the server?

"The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header for the entity being requested."

https://datatracker.ietf.org/doc/html/rfc2617#section-3.2.2


Edit: I've reached out to the dev for the digest_auth crate via email... I was unable to get access to the relevant issue tracker on the gitea instance that hosts the library.

maoertel commented 1 year ago

Hey Daniel,

sorry for late reply, do not have too much time to put into this project currently. Any news from the digest_auth author?

:v:

daniel-widrick commented 1 year ago

I did reach out to the digest_auth dev. I also worked on this some more... I was able to remove the algorithm parameter from a request but the problem remains with the Mikrotik switch.

These requests all validate with third party tools. I've submitted a ticket to Mikrotik about the underlying issue.. but am not super hopeful on a reasonable response.

This could probably be closed. I doubt the problem exists outside of Mikrotik's implementation in SwOS.

maoertel commented 1 year ago

Oh, ok, feel free to open it again or even come up with a PR when diqwest can solve the issue.