Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Extension verifies without correct header #4

thejnich opened this Issue Mar 22, 2012 · 3 comments


None yet
1 participant

thejnich commented Mar 22, 2012

Once I modified the python code to send hex, the extension successfully decrypts it and posts the response as it should, but I noticed that the lock appears, even though I have not implemented any verification of the client post. When I get the token back from the client, I send stage2 header, but do not set the verification to true or anything else, yet the extension says it is verified.
Don't know if anyone else noticed this, but might be something in the extension we should investigate?


ghost commented Mar 22, 2012

Try refreshing the site and seeing if the session remains authenticated (lock symbol). If it does then there is a serious problem, otherwise you might just be sending back X-GPGAuth-Authenticated: true or some such thing, but persistent session storage is actually broken. EDIT just read how you aren't setting this to true. will look into it.

I'll look at your code and let you know if I come up with anything. The perl backend is also really messy -- the gnupg bindings are clunky as hell and this whole having to setup keys ahead of time is starting to get to me. Apparently you can have keys that interoperate between openssl and gnupg but I have yet to make this work. Sorry for getting off topic.


thejnich commented Mar 22, 2012

After refresh, it does not remain authenticated, as expected. But it still should not be authenticating at all. My response headers in stage 2 are:
--> HTTP/1.1 200 OK
X-GPGAuth-Authenticated: false
Content-Length: 2400
X-GPGAuth-Logout-URL: /index.py?logout
X-GPGAuth-Pubkey-URL: /server.pub
X-GPGAuth-Progress: stage2
X-GPGAuth-Requested: true
X-GPGAuth-Version: 1.3.0
X-GPGAuth-Verify-URL: /index.py?server_verify
X-GPGAuth-Login-URL: /index.py?login
Content-Type: text/html
Date: Thu, 22 Mar 2012 23:37:30 GMT
Server: lighttpd/1.4.28

Authenticated is 'false'.
Not that this is a huge problem, as long as the backend knows if a user is authenticated or not. It doesn't really matter if the client thinks it is, it won't be able to access secure pages. It would be nice for consistency though.


ghost commented Mar 23, 2012

Yeah I think you hit a genuine bug here, all your headers look OK. Another reason why we should be looking at the extension code.

@thejnich thejnich closed this Jun 1, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment