Forum

ReverseProxy HTTPS<==>HTTP on the same processor

Paul
30 April 2018, 22:59
Hi All,

Hiawatha Version: 10.7
Operating System: Embedded Linux 2.6.37

I have a embedded system (ARM processor) that has a web control interface (HTTP only) that is tightly integrated with the application that controls the system (i.e. it is the same process). I am tasked with adding HTTPS support to the system.

Instead of adding HTTPS support to the application, I was hoping to run Hiawatha in ReverseProxy mode and thus convert the HTTPS coming from the client to the HTTP application backend.

I have downloaded and compiled Hiawatha for the ARM and I have been able to establish a HTTPS connection to it and load Hiawatha's sample webpage. However, I have not been able to configure the ReverseProxy so that I can load the pages from the application's webserver.

The embedded web pages are accessed with a IP address only (i.e. https://10.10.0.171/). Here is my hiawatha.conf:

# Hiawatha main configuration file
#

# VARIABLES
# With 'set', you can declare a variable. Make sure the name of the
# variable doesn't conflict with any of the configuration options.
# The variables are case-sensitive and cannot be redeclared.
#
#set LOCALHOST = 127.0.0.0/8


# GENERAL SETTINGS
#
#ServerId = www-data
ConnectionsTotal = 1000
ConnectionsPerIP = 25
SystemLogfile = /usr/local/var/log/hiawatha/system.log
GarbageLogfile = /usr/local/var/log/hiawatha/garbage.log


# BINDING SETTINGS
# A binding is where a client can connect to.
#
#Binding {
# Port = 80
#}
#
Binding {
Port = 443
TLScertFile = /usr/local/etc/hiawatha/tls/localhost.pem
Interface = 10.10.0.171
MaxRequestSize = 2048
TimeForRequest = 30
}


# BANNING SETTINGS
# Deny service to clients who misbehave.
#
#BanOnGarbage = 300
#BanOnMaxPerIP = 60
#BanOnMaxReqSize = 300
#KickOnBan = yes
#RebanDuringBan = yes


# COMMON GATEWAY INTERFACE (CGI) SETTINGS
# These settings can be used to run CGI applications.
#
#CGIhandler = /usr/bin/perl:pl
#CGIhandler = /usr/bin/php-cgi:php
#CGIhandler = /usr/bin/python:py
#CGIhandler = /usr/bin/ruby:rb
#CGIhandler = /usr/bin/ssi-cgi:shtml
#CGIextension = cgi
#
#FastCGIserver {
# FastCGIid = PHP7
# ConnectTo = /run/php/php7.0-fpm.sock
# Extension = php
#}


# URL TOOLKIT
# This URL toolkit rule was made for the Banshee PHP framework,
# which can be downloaded from http://www.banshee-php.org/
#
#UrlToolkit {
# ToolkitID = banshee
# RequestURI isfile Return
# Match ^/(css|files|fonts|images|js)($|/) Return
# Match ^/(favicon.ico|robots.txt)$ Return
# Match [^?]*(\?.*)? Rewrite /index.php$1
#}


# DIRECTORY SETTINGS
# You can specify some settings per directory.
#
#Directory {
# DirectoryID = static
# Path = /css, /fonts, /images, /js
# ExpirePeriod = 2 weeks
#}
#
#Directory {
# DirectoryID = files
# Path = /files
# ShowIndex = yes
# StartFile = index.html
# ExecuteCGI = no
#}


# DEFAULT WEBSITE
# It is wise to use your IP address as the hostname of the default website
# and give it a blank webpage. By doing so, automated webscanners won't find
# your possible vulnerable website.
#
Hostname = 127.0.0.1
WebsiteRoot = /usr/local/var/www/hiawatha
StartFile = index.html
AccessLogfile = /usr/local/var/log/hiawatha/access.log
ErrorLogfile = /usr/local/var/log/hiawatha/error.log


# VIRTUAL HOSTS
# Use a VirtualHost section for each website you want to host.
#
#VirtualHost {
# Hostname = www.my-domain.com
# WebsiteRoot = /var/www/my-domain/public
# AccessLogfile = /var/www/my-domain/log/access.log
# ErrorLogfile = /var/www/my-domain/log/error.log
# TimeForCGI = 5
# UseFastCGI = PHP7
# UseToolkit = banshee
# UseDirectory = static, files
#}
VirtualHost {
Hostname = 10.10.0.171
WebsiteRoot = /var/www/empty
ReverseProxy ^.* http://10.10.0.171:80/
}
Paul
30 April 2018, 23:12
I forgot to mention in the error.log I get the following:

error connecting to reverse proxy
Nicolas
1 May 2018, 11:12
Hello,

I'm a noob with ReverseProxy and IP Adresses are still a bit obscure, but I see two differences between my ReverseProxy line and yours. I'm using the loopback adress and another regular expression. I decided do to it this way after reading multiples topics from this forum about ReverseProxy.

So maybe something like that will work for you too (or maybe only using one modification will be sufficient) :

ReverseProxy .* http://127.0.0.1:80/


If it's still not working, people with a better understanding should be able to help you
Paul
1 May 2018, 18:54
I did some more debugging and found that the HTTP server in the application is receiving the proxied requests from Hiawatha and it is generating a response, but that response is not getting back to Hiawatha for some reason.
Paul
1 May 2018, 20:24
BTW, I used Nicolas' suggestion to use the loopback interface. Thanks, Nicolas!

I tried using the -DENABLE_DEBUG option in cmake to see if I can get more information from Hiawatha, but I get the following message:

CMake Warning:
Manually-specified variables were not used by the project:

ENABLE_DEBUG


Is -DENABLE_DEBUG still supported?
Hugo Leisink
1 May 2018, 21:02
The IP of your webserver’s binding is the same as the one in your ReverseProxy setting. Are you that’s correct?

Use -DENABLE_DEBUG=on instead. But that flag is for developers only. So, forget about that one.
Paul
2 May 2018, 19:57
Hi Hugo,

I thought that was the way to do it since Hiawatha and the backend webserver were both running on the same processor. I also tried Nicolas' suggestion of using the loopback interface (127.0.0.1) in the ReverseProxy setting, but still no luck.

Today, I also tried running the ReverseProxy on one processor and running the backend webserver on another processor. I still wasn't able to load the page through Hiawatha's ReverseProxy. I changed the VirtualHost section of hiawatha.conf as follows (where 10.10.40.105 is the address of the processor the backend server was running on):

VirtualHost {
Hostname = 10.10.0.171
WebsiteRoot = /var/www/empty
ReverseProxy .* http://10.10.40.105/ keep-alive
}


I put Wireshark in the middle and I was able to see the GET message from Hiawatha (10.10.0.99 is the address of the PC running the web browser:

GET / HTTP/1.1
X-Hiawatha-RProxy-ID: 48c135142c
Host: 10.10.0.171
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Forwarded: for="10.10.0.99"
X-Forwarded-For: 10.10.0.99
X-Forwarded-Proto: https
X-Forwarded-Host: 10.10.0.171
X-Forwarded-Port: 443


and the OK response from the backend server:

HTTP/1.1 200 OK
Server: DDV/1.0
Content-type: text/html
Connection: close

<!DOCTYPE html>
<html>
...


But I never see the web page displayed in my browser.
Paul
3 May 2018, 17:32
Today, I tried doing a HTTP<==>HTTP reverse proxy and it did not work either. I can still see the http responses from the backend server in Wireshark, but they never make it back to the web browser. Could Embedded Linux on the processor running Hiawatha be blocking the http responses from the backend server? I don't know much about firewalls in Linux and how to configure them.
Hugo Leisink
3 May 2018, 20:32
It could as well be a bug in Hiawatha’s reverse proxy. What backend app do you use?
Paul
3 May 2018, 20:56
It is an application I wrote to control video compression hardware. The http server code part of the app originally came from the eCos project. All the html pages are generated by C code.

FYI, I ran tcpdump on the processor running Hiawatha, and it displays the http response from the backend server.
Paul
7 May 2018, 22:20
I thought the issues I was having could be due to me testing via on a network file system (NFS). However, I ran Hiawatha out of flash and I am still not able to access the backend server.
Paul
8 May 2018, 22:28
We found what was causing the problem!

Our backend webserver was terminating HTTP header lines with a LF instead of a CRLF. It's never caused problems with the web browsers we've used, but Hiawatha did not like it. We changed our backend server to terminate header lines with CRLF and the ReverseProxy worked like a charm!
Hugo Leisink
9 May 2018, 00:16
Ah, that again. Yeah, the standard clearly says a HTTP header line should end with \r\n. I'll try to remember this when the next reverse proxy issue is reported. Good to hear it works now!
This topic has been closed.