Closed szaimen closed 4 years ago
HSTS - another steaming pile of dog turd... I hate like they hype stuff using their ratings...
@mamama1 So what would you suggest? Just leave it as it is?
No, sorry just had to rant about this. The other issues are kind of serious, I guess, although most of them don't have anything to do with encryption in particular.
Unfortunately, I don't know how to fix them in this case, ignore me... :)
Header set X-XSS-Protection "1; mode=block"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set X-Content-Type-Options nosniff
Header set Content-Security-Policy "frame-ancestors 'self' mynextclouddomain"
I could make it work with that. Problem is, that the Content-Security-Policy isn't set: there must be a defaul-src or script-src tag, which I couldn't make working. btw: the CSP frame-ancestors setting is correct here.
Whut? Our LE implementation gets A rating on Qualys...
This is not for nextcloud itself but for the proxy of e.g. Onlyoffice...
Thing is this, if we want to implement stricter TLS / Apache headers, we must test that nothing breaks.
For me, it's just a proxy, and no traffic is allowed through Nextcloud anyway. If we can imporve it with small steps, sure. But everything needs to be tested like 10 times, I mean push all the buttons in the Documentserver, share the document and everything like that.
Either Collabora or OnlyOffice needs to be on a secured connection - even one of the devs recomended against it since it was unnecessary. So if it's F or not, doesn't really matter to me. It's at least better than plain HTTP.
I'm okay with everything except CSP as that tends to break shit if not done precisely correct. :D
Header set X-XSS-Protection "1; mode=block"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set X-Content-Type-Options nosniff
Header set Content-Security-Policy "frame-ancestors 'self' mynextclouddomain"
I successfully tested those header and with all Onlyoffice applications and also callaborating editing of docs. When using those, you get a rating of B+, which is probably okay.
Actually, What I thought about is, that Bitwarden is using the same Proxy setup and because of that probably getting the same result in an SSL test. Isn't that something which should definitely get improved?
This is the default conf for bitwarden nginx. Maybe we can copy over some settings?
#######################################################################
# WARNING: This file is generated. Do not make changes to this file. #
# They will be overwritten on update. You can manage various settings #
# used in this file from the ./bwdata/config.yml file for your #
# installation. #
#######################################################################
server {
listen 8080 default_server;
listen [::]:8080 default_server;
server_name bitwarden.test.com;
include /etc/nginx/security-headers.conf;
location / {
proxy_pass http://web:5000/;
include /etc/nginx/security-headers.conf;
add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com; child-src 'self' https://*.duosecurity.com; frame-src 'self' https://*.duosecurity.com; connect-src 'self' wss://bitwarden.test.com https://api.pwnedpasswords.com https://twofactorauth.org; object-src 'self' blob:;";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Robots-Tag "noindex, nofollow";
}
location /alive {
return 200 'alive';
add_header Content-Type text/plain;
}
location = /app-id.json {
proxy_pass http://web:5000/app-id.json;
include /etc/nginx/security-headers.conf;
proxy_hide_header Content-Type;
add_header Content-Type $fido_content_type;
}
location = /duo-connector.html {
proxy_pass http://web:5000/duo-connector.html;
}
location = /u2f-connector.html {
proxy_pass http://web:5000/u2f-connector.html;
}
location /attachments/ {
proxy_pass http://attachments:5000/;
}
location /api/ {
proxy_pass http://api:5000/;
}
location /identity/ {
proxy_pass http://identity:5000/;
}
# location /sso/ {
# proxy_pass http://sso:5000/;
# }
location /icons/ {
proxy_pass http://icons:5000/;
}
location /notifications/ {
proxy_pass http://notifications:5000/;
}
location /notifications/hub {
proxy_pass http://notifications:5000/hub;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}
location /events/ {
proxy_pass http://events:5000/;
}
location /admin {
proxy_pass http://admin:5000;
include /etc/nginx/security-headers.conf;
add_header X-Frame-Options SAMEORIGIN;
}
}
Bitwarden is using the same Proxy setup
I got A rating with Qualys when we tested a few days ago. Maybe Mozilla is stricter?
No CSP there please.
Bitwarden is using the same Proxy setup
I got A rating with Qualys when we tested a few days ago. Maybe Mozilla is stricter?
I haven't tested the new bitwarden setup with a SSL tester, so don't know... That was just my guess...
Bitwarden is using the same Proxy setup
I got A rating with Qualys when we tested a few days ago. Maybe Mozilla is stricter?
No CSP there please.
Where?
https://www.ssllabs.com/ssltest/
That's what I use for testing.
Hm ya, it looks like mozilla is also scanning request headers and ssllabs not... So I guess the mozilla tool is indeed stricter.
OK, change Collabora and OnlyOffice (in the current PR), wait with Bitwarden - we need more testing.
Thanks!
I've already changed it for Onlyoffice_docker in the PR.
But I didn't test Collabora. Are you sure it will behave comparable?
But I didn't test Collabora. Are you sure it will behave comparable?
Nope, but I thought we could test it.
I won't be able to fire up a VPS for some time now since I'm on parental leave this week - but feel free if you have time. :+1:
But I didn't test Collabora. Are you sure it will behave comparable?
Nope, but I thought we could test it.
I'll put it into the collabora_docker script 👍 Edit: done
I guess for bitwarden we also should check if we need the x-forwarded-for header... https://www.globo.tech/learning-center/x-forwarded-for-ip-apache-web-server/ https://github.com/bitwarden/server/issues/867
OK, please add.
List for bitwarden testing:
a2enmod remoteip
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy # need to add the proxy ipaddress?
We could also try this:
RemoteIPHeader X-Real-IP
RemoteIPHeader X-Forwarded-Proto
also maybe this:
Header set X-XSS-Protection "1; mode=block"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set X-Content-Type-Options nosniff
Header set Content-Security-Policy "frame-ancestors 'self'"
and this?
Header set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com; child-src 'self' https://*.duosecurity.com; frame-src 'self' https://*.duosecurity.com; connect-src 'self' wss://bitwarden.test.com https://api.pwnedpasswords.com https://twofactorauth.org; object-src 'self' blob:;"
For testing this command might be useful:
apache2ctl configtest
I've added some of the stuff that I thin is sane to Bitwarden.
They are hashed out for now, but we can leave it there and remove the hash when tested and confirmed working.
Since all our Proxy configs now are fixed, I'll close this issue.
okay
Or let's keep it open just to remember... :)
It's now fixed.
We use this in:
Hm, I would vote to reopen the issue because we should really check for bitwarden if CSP is possible.
Header set Content-Security-Policy "frame-ancestors 'self'"
Header set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com; child-src 'self' https://*.duosecurity.com; frame-src 'self' https://*.duosecurity.com; connect-src 'self' wss://bitwarden.test.com https://api.pwnedpasswords.com https://twofactorauth.org; object-src 'self' blob:;"
Maybe this could also be a new issue?
I've opened a new one #1378
Hey, I've lately scanned my office domain (currently old Onlyoffice) using this configuration: https://github.com/nextcloud/vm/blob/master/old/onlyoffice.sh#L126-L164 with Mozilla Observatory and this was the result: Could we somehow improve this? Here is a link which covers nearly almost all things: https://geekflare.com/http-header-implementation/