YaCy-Bugtracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000675YaCy[All Projects] Generalpublic2016-07-27 23:062016-08-05 01:27
Reporterluc 
Assigned ToBuBu 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionno change required 
ETAnone 
PlatformOSGNU/LinuxOS VersionDebian Jessie
Product VersionYaCy 1.8 
Target VersionFixed in Version 
Summary0000675: Unauthorized admin features with DIGEST authentication
DescriptionWhen setting YaCy HTTP authentication to DIGEST instead of BASIC, some administration features are still unauthaurized.
The most obvious ones are /ConfigBasic.html and /Steering.html?shutdown= which end with a 401 Unauthaurized HTTP Status code.
Private pages suffixed with "_p" work fine.

It would be good to have Digest HTTP Authentication mode fully working for remotely administered YaCy servers with no TLS, as Basic authentication is well known as unsecure and should not be used without TLS.
Steps To ReproduceAs described in wiki (http://www.yacy-websearch.net/wiki/index.php/En:Security [^]), modify the defaults/web.xml configuration file with <auth-method>DIGEST</auth-method>
Go to a private page such as /ViewLog_p.html : once correct login/password is typed, the page is correctly displayed.

Go to /ConfigBasic.html : result is the following :
HTTP ERROR 401
Problem accessing /ConfigBasic.html. Reason: Unauthorized
Additional InformationSome debugging reveals that Switchboard.adminAuthenticated() function does not support correctly Digest HTTP authentication mode :
- condition "if ( realmValue.length() > 512 )" tests for a too short string
- realmValue itself is not correctly parsed

Many admin features are only activated when Switchboard.adminAuthenticated returns true, and so are missing when using Digest authentication.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0001264)
luc (reporter)
2016-07-27 23:08

 Edit : the original condition is "if ( realmValue.length() > 256 ) "
(0001266)
BuBu (developer)
2016-08-01 01:04

 I was not able to reproduce the described behavior.

Steps to reproduce:

1. change web.xml in defaults auth from BASIC to DIGEST
2. from localhost goto Accounts, set "Access only with qualified account" password for user admin (+ save setting with "Define Administrator" button)
3. restart YaCy
4. access from remote /status.html -> login form -> using user and password just set
5. access /ViewLog_p.html followed by /ConfigBasic.htm followed by /Steering.html
all display and work fine from remote

Do you see any difference in the steps and/or does error appear following this sequence ?
(0001267)
luc (reporter)
2016-08-02 01:02

 Hi, I just tested again and got exactly the same HTTP 401 error...
Precisions :
- run from latest compiled sources from YaCy master github repository
- run from scratch : no previously existing DATA directory
- all settings are default, except admin password and web.xml auth method as described
- I run exactly the same steps as you, except that /Status.html doesn't ask for login/password and display limited public information. Login is only asked when visiting /ViewLog_p.html or another private page
- test configs, all reproducing the issue :
 - Firefox 45 requesting localhost peer on Debian Jessie
 - Firefox 47, IE Edge or Chrome 52, on Windows 10 requesting remote peer on Debian Jessie

I wonder what differ in our configurations which makes it works on yours : existing DATA, browser history... ?
(0001269)
BuBu (developer)
2016-08-02 03:10

 I tested with IE Edge and Firefox 47, but peer runs on Win box.
Also latest source under java 8.
From these differences don't lead me to a idea for a cause.
(0001270)
luc (reporter)
2016-08-02 14:53

 Ok, when having some time I will try to re-run this test with a YaCy peer running on Windows with Java 8.

By the way, I now configure my remote peer with HTTPS enabled + Basic Authentication. This works fine and I hope provides a reasonnable security level, so I also updated the wiki section accordingly.
(0001271)
luc (reporter)
2016-08-04 12:18

 I did not reproduced the issue when running my peer on Windows 10.
And in the meantime I re-installed open jdk on my Debian machines, and guess what? No more problem with Digest Authentication!

I really wonder what initially went wrong... I re-tried many differents steps combinations, using either openjdk 7 or 8, and everything now works fine each time.

I am really sorry to have made loose your time. I think you can now close this issue.
(0001272)
BuBu (developer)
2016-08-05 01:27

 Great to get that info and to know it works.
I still consider to make DIGEST default one day (but currently there are some backward compatibility requirements, as far as I know, that holds me up)

- Issue History
Date Modified Username Field Change
2016-07-27 23:06 luc New Issue
2016-07-27 23:08 luc Note Added: 0001264
2016-08-01 01:04 BuBu Note Added: 0001266
2016-08-01 01:04 BuBu Assigned To => BuBu
2016-08-01 01:04 BuBu Status new => feedback
2016-08-02 01:02 luc Note Added: 0001267
2016-08-02 01:02 luc Status feedback => assigned
2016-08-02 03:10 BuBu Note Added: 0001269
2016-08-02 14:53 luc Note Added: 0001270
2016-08-04 12:18 luc Note Added: 0001271
2016-08-05 01:27 BuBu Note Added: 0001272
2016-08-05 01:27 BuBu Status assigned => resolved
2016-08-05 01:27 BuBu Resolution open => no change required

Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker