HTTP instead of HTTPS

[oe1agf]

Hi,
how would I go about changing Proxmox to serve its admin pages using HTTP? Background being that I use it for the HAMNET, a primarily radio-bases intranet for radio amateurs, and in amateur radio we are not allowed to use any form of encryption.

Thank you for any suggestions.

Jörg

 

[t.lamprecht]

Hi,

changing it in Proxmox VE is not really supported, it's baked quite into it as normally one always want to have secure communication.

You could try running a reverse HTTP proxy (e.g., nginx) in front of it. You could start off with:
https://pve.proxmox.com/wiki/Web_Interface_Via_Nginx_Proxy
Drop the rewrite from HTTP to HTTPS and make the nginx itself listen on HTTP - I did not try it but it should work.

Anyway, how does HAMNET then handles transmitting of secrets like user/password credentials?

 

[c.weilguny]

Did you talk to other radio amateurs about that, or did somebody request that? I don't think, that the prohibition of encryption also has to be applied to this layer. If it would, then e.g. the websites of e.g. the ÖVSV or the DARC also wouldn't be allowed to be served over https. That would be like if you are not allowed to lock the door of your house only because you have amateur radio equipment inside
Or are you talking to the Proxmox GUI over HAMNET?

73 de OE5WEI

 

[oe1agf]

Well, the laws and regulations both in Austria and in Germany (and I believe all over the world, too) are quite clear about it: we are not allowed to use encrypted traffic in radio transmissions; more specifically it says: "you must use open language", which includes any form of data transmissions, such as radio teletype (RTTY) and WiFi (which the HAMNET radio link layer is, essentially). I know that in the case of Proxmox this is often quite happily ignore by operators, but that doesn't automatically remove the requirement...

@OE5WEI: you will notice that https access to HAMNET infrastructure devices (primarily MikroTik or Ubiquiti routers) is disabled for the very same reason. And, off course, this does not apply to amateur radio websites onthe internet, such as oevsv.at and darc.de. If those sites are also hosted in the HAMNET (e.g. on ampr.org and ampr.at), these sites will not use https! And, if you lock your door remotely using amateur radio frequencies, yes, you must use unencrypted traffic (and use another clever form of rolling pin code or so). So that is really a poor comparison!

@thomas: the accepted forms of protection of radio traffic (and that includes HAMNET infrastructure) are: you must not transmit information that has any other significance than for the hobby itself (except in emergencies and/or by request of civil authorities), i.e. is so unimportant that eavesdropping into communication causes neither harm nor damage. And the HAMNET uses frequencies (except in Austria) and bandwidths outside the normal WiFi spectrum (but inside the amateur radio allocations) as a protective measure.

To conclude: I was asking the above question out of pure interest. I guess nobody will bother anyway. The servers I host on Proxmox (and in the HAMNET) are all using unencrypted traffic; I would argue that the host (i.e. PVE) does not contain any form of information that might be relevant to the actual content of the radio traffic. But still, if push came to shove, I wouldn't like to take my Proxmox hosted sites down because of that.

Thanks for any suggestions, though, and for Proxmox, btw.

73, Jörg, (73 being the international morse code for "Best Regards" and is accepted as "Open Language")
OE1AGF/DF3EI

 

[oe1agf]

Using Thomas' suggestions from above I have tried the following configuration:

upstream proxmox {
    server "pve.db0bc.ampr.org";
}

server {
    listen 80;
    server_name _;
    proxy_redirect off;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass https://44.149.38.130:8006;
        proxy_buffering off;
        client_max_body_size 0;
        proxy_connect_timeout  3600s;
        proxy_read_timeout  3600s;
        proxy_send_timeout  3600s;
        send_timeout  3600s;
    }
}

This works as far as the login is concerned, but then pops up an alert "No ticket!". I shall report on any progress... Thanks again!

 

[fabian]

the ticket is transmitted as a cookie which has the 'secure' flag set, which means the browser will only send it via HTTPS.

should be "fixable" (as in, you can work around the limitations in your environment, this is not a good idea in general!)
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cookie_flags