Our cycber security have recommended the introduction of HTTP Strict-Transport-Security response headers, but cannot see anywhere in VisualSVN (or the configuration of it) to do this.
This is for VisualSVN Enterprise 4.2.2 (using Apache 1.10.6) running on Windows 2019 DataCenter.
I see no separate installation of Apache, no presence of a httpd.exe on the server and there's a header warning in the httpd.conf file which advises tha the conf will be overwritten when/if the VisualSVN service is started.
You can add the following line to the %VISUALSVN_SERVER%conf\httpd-custom.conf file and restart the VisualSVN Server service:
Header always set Strict-Transport-Security "max-age=31536000"
Note that you may need to replace the max-age value with another one depending on your requirements.
Related
WSO2 APIM has a default User-Agent header which is:
Synapse-PT-HttpComponents-NIO
I want to change it to something else, so i have added header mediation from the publisher run time configuration but no luck, also i tried to add this line http.user.agent.preserve=true in passthru-http.properties as many people said but whenever i restart the server it is removed from the file.
How I can accomplish it ?
I am using wso2am-3.2.0
In APIM 3.2.0, we use deployment.toml file to add/modify configurations. If you edit the configuration files directly, it will be overridden by the configs in the deployment.toml during server startup. Try adding the below values in deployment.toml found inside <APIM_HOME>/repository/conf/
[passthru_http]
'http.user.agent.preserve'=true
For backwards compatibility reasons I need a Geode Jetty server to use TLSv1 and not 1.1 or 1.2
With ssl-enabled-components=web and ssl-protocols=TLSv1.0 set in gemfire.properties then when I start the Geode and check the HTTPS connectivity with SSL Labs then I get a TLS result:
I am looking for the TLS 1.1 and TLS 1.0 checks to also say Yes not No
The Geode SSL docs say Make sure your Java installation includes the JSSE API and familiarize yourself with its use.
The JSSE is about the java.security config in the JRE/lib/security directory. I set this not to disable any security algorithms and restarted Geode but the results are the same. TLS 1.1 and 1.0 are failing the SSL Labs test above.
Is there a way to force Geode to start with https.protocols=TLSv1 ?
When I try to start a locator with that using --J=-XX:https.protocols=TLSv1 then I get
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized VM option 'https.protocols=TLSv1'
There is no separate Jetty config I can find...
Update --J=-Dhttps.protocols=TLSv1 is the correct setting to assign TLS protocols to the JVM and that works on starting Geode locator and server.
Update When I set java.security setting jdk.tls.disabledAlgorithms=TLSv1.1, TLSv1.2 like the opposite of this then it's not possible to communicate via HTTPS with the Jetty server at all. This makes me think the Geode / Jetty ssl-protocols=TLSv1.0 setting does not apply either?
The Jetty config says TLS v1.0, v1.1 and SSL v3 are no longer supported by default. If your Jetty implementation requires these protocols for legacy support, they can be enabled manually.
Is there a way to configure Jetty with Geode?
I don't believe you can currently achieve this. Mainly because of how Jetty is being configured internally. Jetty maintains a list of excluded ciphers defined by the regex ^.*_(MD5|SHA|SHA1)$. Unfortunately, it seems that this list trumps any ciphers which may be added as 'included'. Here's a very simple Jetty example that I used for testing: https://gist.github.com/jdeppe-pivotal/c0c6e7de4282bc077357749fc91bc44f. Jetty will produce a nice dump of the ciphers and protocols it is using when you run this.
As it stands, you can perform a successful request with the following curl: curl -k -v --tlsv1.2 https://localhost:8081/. Now, if you try that with tlsv1.0 it will fail because the necessary cipher suites are all disabled. However, if you uncomment the line: sslContextFactory.setExcludeCipherSuites() then things should start working. What this does is to remove all the current excluded ciphers (and allow them to be used). Unfortunately if you only try and add ciphers (without also excluding everything) things still don't work. Note that by doing this, Jetty is still configured for TLSv1.2 (and 1.1 and 1.0) but the client can use a lower protocol version.
The bottom line is that Geode does not explicitly exclude any ciphers from Jetty. Thus if you're hoping to add the necessary ciphers, they will most likely not be effective. I've opened a bug for this: https://issues.apache.org/jira/browse/GEODE-3891
I'm working on a Python project that depends on a package that runs Gunicorn as a web server. I need to support https, but the Gunicorn configuration exposed by the package doesn't allow me to pass in keyfile or certfile options, and 'http' is hard-coded throughout the package.
I was wondering if there's some easy way to get https working transparently between clients and Gunicorn without Gunicorn knowing about it, on OpenShift or any popular PaaS.
Take a look at the solution purposed this Openshift KB https://www.openshift.com/kb/kb-e1044-how-to-redirect-traffic-to-https
OpenShift Online apparently handles this automatically by default.
Just change the http to https in the application url they give you (https://xxx-yyy.rhcloud.com) and you've got TLS using their *.rhcloud.com certificate.
I was expecting more configuration and just needed somebody to tell me "just change the url to https".
I intend to run a Jetty server (for generating PDF files with PDFreactor) on a dedicated (virtual) machine; I don't want to have it on my webserver.
According to the PDFreactor documentation, the Jetty server must run on localhost to be usable by the Python API; but a port and host can be given to the PDFreactor constructor, and apparently the restriction to listen to localhost only can be lifted.
Can Jetty be configured to accept requests from some whitelist of hosts only, or is it preferable to put it in a VirtualHost and let apache httpd do the work?
In the past I used an ftp server, connected via "ftp" from the client and "GET" to copy one file from the remote machine to the local machine.
Is it possible to do the same but with the server only running a http server?
Server: GoAhead Web Server.
Both client and http server on Windows.
The copy can be either initiated from the browser or if need a separate program can be written on the client. (i.e. - any windows api calls to copy a file from http server?)
(Also, the files may not be in the http root web directory but somewhere else on the server....can that happen?)
HTTP servers will only serve up files that are located within the site's document root. If you want to get at files that are outside the document root, you'll have to have a script serve up that file from the server (php, perl, cgi, etc...), or find some way of getting that file "inside" the document root.
To download files within the site's document root, you just hit a url pointing at that file - that's the core point of HTTP - you're just downloading content from the site.
HTTP servers will also not accept uploads without an intermediate script to handle it. If they did, you could upload any file you wanted to any server, anywhere.
What others mentioned about HTTP servers is true, but GoAhead Web Server is not a only a HTTP server. It provides many other features on top of that. And file upload seems possible, with help of a patch. More info:
https://embedthis.com/goahead/
Use WebDav for this purpose.