putty-pkix-v0.73: "Server refused our key" #2
Assignees
Comments
|
Hi wylda, Keep in mind that the prefix x509:// is using the not often used x509v3-sign-rsa key type which was part of an earlier draft. While the prefix cert:// is fully compatible to the ssh-rsa key type, as the version from Ulf Frisk (https://github.com/ufrisk/puttywincrypt) does. Both should key types work with the ssh from Roumen Petrov (https://roumenpetrov.info/secsh/). Thank you for your feedback. |
svenso
pushed a commit
that referenced
this issue
Jun 3, 2022
When do_paint breaks up a line of terminal text into contiguous runs of characters to treat the same, one of the criteria it uses is, 'Does this character even need redrawing? (or is it already displayed correctly from the previous redraw?)' When we encounter a character that matches its previous value, we end the previous run of characters, so that we can skip the one we've just encountered. That check was not taking account of the 'truecolour' field of the termchar it was checking. So it would sometimes falsely believe the character to be equivalent to its previously drawn value, even when in fact it was not, and hence insert a run break, anticipating that the previous character needed drawing and the current one did not. This didn't cause a _wrong_ redraw, because there's a separate loop further on which re-checks whether to actually draw things, which didn't make the same error. So the character that loop #1 thought didn't need a redraw, loop #2 knew _did_ need a redraw, and hence, everything did get redrawn. But by the time loop #2 is running, it's too late to change the run boundaries. So everything does get redrawn, but in much smaller chunks than it could have been. The net effect was that if the screen was filled with text displayed in true colour, and you changed it to the _same_ text in a different colour, then the whole terminal would be redrawn in one-character increments instead of the usual behaviour of folding together runs that can be drawn in one go. Thanks to Bradley Smith for debugging this very confusing issue!
svenso
pushed a commit
that referenced
this issue
Jun 3, 2022
Now, we always try an initial CONNECT request with no auth at all, and wait for the proxy to reject it before sending a second try with auth. That way, we can wait to see what _kind_ of authentication the proxy requests, which will enable us to support something more secure than Basic, such as HTTP Digest. (I mean, it would _work_ to try Basic in request #1 and then retrying with Digest in #2 when the proxy asks for it. But if the aim of using Digest is to avoid sending the password in cleartext, it defeats the entire purpose to have sent it in cleartext anyway by the time you realise the server is prepared to do something better!)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, i have an issue with keys protected by TPM. But there seems to be an easy work around
This does not work ("Server refused our key"):
x509://thumbprint=aaac12a93dad48260c373189b4b3e08dfaaecaaa
But this one works perfectly:
cert://thumbprint=aaac12a93dad48260c373189b4b3e08dfaaecaaa
Thank you for your great work!
The text was updated successfully, but these errors were encountered: