Consider this HAProxy configuration here:
global
chroot /var/lib/haproxy
user haproxy
group haproxy
defaults
timeout connect 10s
timeout client 50s
timeout server 50s
frontend fe_https_tomcat
mode tcp
bind *:443 ssl crt /path/cert.pem alpn h2,http/1.1
default_backend be_tomcat
backend be_tomcat
mode tcp
server localhost localhost:8081 check
The issue I have is that WebSocket do not seem to get through. My guess was that in tcp mode everything would pass through. Looks like it doesn't ... :-)
The server responds with an error 403 when the WebSocket connection is getting established.
Note that with the following http-mode setup, the WebSocket just works:
frontend fe_http_8080
mode http
bind *:8080
default_backend be_tomcat_8080
backend be_tomcat_8080
mode http
server localhost localhost:8081 check
Note that I need tcp-mode to have http/2 working.
The issue was not related to HAProxy at the end, but to the WebSocket setup in Spring.
This fixed it:
-registry.addHandler(webSocketHandler, "/ws");
+registry.addHandler(webSocketHandler, "/ws").setAllowedOrigins("*");
Related
Neo4J server configuration allows to set up a server-side policy to secure both HTTPS and BOLT connections.
In my installation I secured the BOLT connection by setting up a policy with PEM public and private key and settings:
dbms.connector.bolt.enabled=true
dbms.connector.bolt.tls_level=REQUIRED
bolt.ssl_policy=my_policy
dbms.ssl.policy.my_policy..base_directory=...
...
The set up works with a browser client. When I connect to the server through HTTPS, I am able to log in using ":server connect" command and use Neo4J browser with my server.
What I cannot do is figure out how other client can connect to Neo4J with secure BOLT protocol. Specifically, I tried connecting from cypher-shell and from a Java client (using Java Driver v 1.6). When TLS for BOLT is disabled, both connect without a hitch. Enabling TLS causes bad_certificate error in both clients.
I tried starting both cypher-shell and my Java client by passing JVM properties pointing to my trust store and key store
(-Djavax.net.ssl.keyStore=...
-Djavax.net.ssl.keyStorePassword=...
-Djavax.net.ssl.trustStore=...
-Djavax.net.ssl.trustStorePassword=...)
These properties have no effect on either Neo4J client. I am getting a bad_certificate exception.
I tried enabling SSL debugging (-Djavax.net.debug=ssl,handshake). Calling the Java client or cypher-shell with keystore and truststore parameters has no effect on the SSL debug output.
How do I connect to the server with TLS for BOLT enabled from cypher-shell or a Java client?
Thank you.
I am using haproxy for port forwarding to Bitbucket server ssh. Here's haproxy config:
frontend sshd
bind *:7999
default_backend ssh
timeout client 1h
backend ssh
mode tcp
server localhost-bitbucket-ssh 127.0.0.1:7999 check port 7999
However if i do:
sudo haproxy -f haproxy.cfg
i am getting the following error:
[ALERT] 305/201411 (4168) : http frontend 'sshd' (haproxy.cfg:38) tries to use incompatible tcp backend 'ssh' (haproxy.cfg:43) as its default backend (see 'mode').
[ALERT] 305/201411 (4168) : Fatal errors found in configuration.
But i was referring to an official atlassian guide: https://confluence.atlassian.com/bitbucketserver/setting-up-ssh-port-forwarding-776640364.html are they wrong?
Also if i start haproxy before bitbucket server, bitbucket server cannot start on port 7999. I am totally confused. I have paid for that software and now i need to figure it out myself how to configure it for more than 2 days...
UPDATE
It was UFW as Thomj mentioned. But for what purposes do i need haproxy? If i can't bind Bitbucket's ssh to 22 port? I don't like to set port number.
The frontend configuration is defaulting to a mode of http which can't use a backend that's configured for tcp. Try adding 'mode tcp' to the frontend:
frontend sshd
bind *:7999
default_backend ssh
timeout client 1h
mode tcp
We have a java web server which is able to serve content over h2c (HTTP/2 clear text)
We would like to reverse proxy connections established using h2 (i.e. standard HTTP/2 over SSL) to the java server in h2c.
Enabling HTTP/2 on nginx is simple enough and handling incoming h2 connections works fine.
How do we tell nginx to proxy the connection using h2c rather than http/1.1 ?
Note: a non-nginx solution may be acceptable
server {
listen 443 ssl http2 default_server;
server_name localhost;
ssl_certificate /opt/nginx/certificates/???.pem;
ssl_certificate_key /opt/nginx/certificates/???.pk8.key.pem;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:8080/; ## <---- h2c here rather than http/1.1
}
}
CONCLUSION (June 2016)
This can be done with haproxy using a configuration file as simple as the one below.
Querying (HttpServletRequest) req.getProtocol() clearly returns HTTP/2.0
global
tune.ssl.default-dh-param 1024
defaults
timeout connect 10000ms
timeout client 60000ms
timeout server 60000ms
frontend fe_http
mode http
bind *:80
# Redirect to https
redirect scheme https code 301
frontend fe_https
mode tcp
bind *:443 ssl no-sslv3 crt mydomain.pem ciphers TLSv1.2 alpn h2,http/1.1
default_backend be_http
backend be_http
mode tcp
server domain 127.0.0.1:8080
HAProxy does support that.
HAProxy can offload TLS and forward to a backend that speaks h2c.
Details on how to setup this configuration are available in this blog post.
I use SilverTunnel NG Netlib Java-library for connecting to TOR from Java.
HTTP connection via TOR to port 80 and a direct HTTPS connection to port 443 connection works fine.
But, when I'm trying to establish a HTTPS connection via TOR to 443 port,
I get answer from server
400 The plain HTTP request was sent to HTTPS port.
How do I fix this?
So I am using HAProxy in front of Jetty servlets.
The goal at the moment is just proof of concept and load and stress testing once everything's configured.
However I have a problem configuring haproxy. I know that it's not a problem with my application cause I have nginx(tengine) running and everything works properly. So it has to be something with the haproxy configuration or just the way haproxy works is not suitable for my needs.
So what my client tries to do is connect to haproxy using two different connections and keep them open:
Connect with a chunked streaming mode for upload.
Connect with a normal mode and establish a download channel.
Here's how my haproxy.conf file looks like:
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
# ca-base /etc/ssl/certs
# crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL).
ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
maxconn 2048
defaults
log global
mode http
option forwardfor
option http-server-close
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
stats enable
stats uri /stats
stats realm Haproxy\ Statistics
stats auth user:password
frontend www-http
bind *:80
reqadd X-Forwarded-Proto:\ http
default_backend www-backend
frontend www-https
bind *:443 ssl crt /etc/haproxy/server.pem
reqadd X-Forwarded-Proto:\ https
default_backend www-backend
backend www-backend
redirect scheme https if !{ ssl_fc }
server www-1 localhost:8080 check maxconn 2048
And here's what my logs say when I try to access port 443:
Sep 17 11:10:18 xxxxx-pc haproxy[15993]: 127.0.0.1:32875 [17/Sep/2014:11:10:18.464] www- https~ www-backend/www-1 0/0/0/-1/1 502 212 - - PH-- 0/0/0/0/0 0/0 "GET /test HTTP/1.1"
Any ideas what the problem might be?
An issue with the configuration or ?
Thanks.
PH means that haproxy rejected the header from the backend because it was malformed.
http://www.haproxy.org/download/1.4/doc/configuration.txt
PH - The proxy blocked the server's response, because it was invalid,
incomplete, dangerous (cache control), or matched a security filter.
In any case, an HTTP 502 error is sent to the client. One possible
cause for this error is an invalid syntax in an HTTP header name
containing unauthorized characters. It is also possible but quite
rare, that the proxy blocked a chunked-encoding request from the
client due to an invalid syntax, before the server responded. In this
case, an HTTP 400 error is sent to the client and reported in the
logs.