@Lan
That's something I'm working on at the moment, offering ECC on other ports outside of 5060.
I'm pretty sure I've figured out a way to do ECC & RSA instances on the same IP both on ports 1-29999 (excluding 30000-65535 since that's reserved for port forwarding).
For UDP, the iptables u32 module is used to do this. For TCP, haproxy is used. With the haproxy setup, it'll be fairly easy to also add SSH & SSL tunneling to the mix as well, also on the above ports.
All that's left is to do more tests from different devices to make sure it actually works in all scenarios.
If I can get it to work the way I imagine it will, it means all of our current VPN IPs (probably excluding the legacy ones) will have RSA & ECC OpenVPN and Wireguard on all UDP ports of every IP, and for TCP it would be RSA & ECC OpenVPN plus SSL & SSH tunneling on all TCP ports of every IP.
The only thing I know I won't be able to implement is Ed25519 or Ed448 in the same way, so those two will have to continue to stay on ports 5061 and 5062. That should be fine though since most customers aren't using OpenSSL 1.1.1 yet, which both of those require.

[quote="df"]@Guest
We are planning to add stunnel some time in the near future.
For now, most DPI can be bypassed by simply using our ECC instances, since they don't disclose the OpenVPN handshake whenever you connect (thanks to --tls-crypt)[/quote]

Stunnel would be great -- I suffer a lot due to DPI, and the high port used by the ECC instances I think does me no favours.

@Guest
We are planning to add stunnel some time in the near future.
For now, most DPI can be bypassed by simply using our ECC instances, since they don't disclose the OpenVPN handshake whenever you connect (thanks to --tls-crypt)

[quote="vinchat"]@parityboy ok thanks. It's more that I would like to have one VPN to "rule 'em all" as in: provides anonymity for personal activities and that can bypass the DPI firewall at my office. Hopefully CS will provide SSL wrapping in the future..[/quote]

+1

It's been almost 4 years. DPI is becoming very common in public WiFi hotspots all over the US. I'd say about 25% of the libraries I visit won't let me connect to cryptostorm using openvpn.

Is cryptostorm any closer to being able to wrap my openvpn connection in stunnel over port 443?

@parityboy ok thanks. It's more that I would like to have one VPN to "rule 'em all" as in: provides anonymity for personal activities and that can bypass the DPI firewall at my office. Hopefully CS will provide SSL wrapping in the future..

[b]@OP[/b]

[b]1.[/b] You could connect over Tor, but that's likely to be dog-slow and your ISP will know you're using Tor
[b]2.[/b] You could use another VPN provider with OpenVPN to provide a first connection, but then your ISP will know you've up with that provider instead of CS.

Basically, there's no way around it. You're gonna expose your IP address [i]somewhere[/i], it's simply a matter of where.

Thanks guys.

Is there any other way of masking/hiding CS's VPN connection over port 443?

[b]@Tealc[/b]

You're half right. :) Yes, CryptoStorm uses port 443, but it sends UDP traffic to that port, not TCP. HTTPS uses TCP. A strict firewall will permit only TCP traffic on that port, most will permit both.

[i]stunnel[/i] is designed to carry [i]TCP[/i] traffic over an SSL link, so it could be that it won't pass UDP traffic. See [url=https://www.stunnel.org/faq.html#applications]here[/url].

Doesn't CS uses already the 443 port to connect? Doesn't most firewall believed that this is actually HTTPS traffic an not OpenVPN?

The *.ssl certificate can easily be modified to point to cryptostorm servers. The ovpn however, is telling me it's invalid when I change it like so (changing remote, removing random, and adding proto udp):

[code]# this is the cryptostorm.is client settings file, versioning...
# cstorm_mac_dynamic_1-4 - post-heartbleed

# it is intended to provide connection to a dynamically loadbalanced pool of cs machines worldwide
# DNS resolver redundancy provided by TLD-striped, randomised lookup queries
# Chelsea Manning is indeed a badassed chick: #FreeChelsea!
# also... FuckTheNSA - for reals


client
dev tun
resolv-retry 16
nobind
float
proto udp

# txqueuelen 686
# expanded packet queue plane, to improve throughput on high-capacity sessions
# NOTE: keep this item commented out if using Viscosity as a client; see viscosity.cryptostorm.org

sndbuf size 1655368
rcvbuf size 1655368
# increase pre-ring packet buffering cache, to improve high-throughput session performance

#remote-random
# randomizes selection of connection profile from list below, for redundancy against...
# DNS blacklisting-based session blocking attacks

<connection>
remote 127.0.0.1 443
</connection>

# <connection>
# remote raw-balancer-dynamic.cryptostorm.org 443 udp
# </connection>
#
# <connection>
# remote raw-balancer-dynamic.cryptostorm.nu 443 udp
# </connection>
#
# <connection>
# remote raw-balancer-dynamic.cstorm.pw 443 udp
# </connection>

comp-lzo no
# specifies refusal of link-layer compression defaults
# we prefer compression be handled elsewhere in the OSI layers
# see forum for ongoing discussion - https://cryptostorm.org/viewtopic.php?f=38&t=5981

down-pre
# runs client-side "down" script prior to shutdown, to help minimise risk...
# of session termination packet leakage

allow-pull-fqdn
# allows client to pull DNS names from server
# we don't use but may in future leakblock integration

explicit-exit-notify 3
# attempts to notify exit node when client session is terminated
# strengthens MiTM protections for orphan sessions

hand-window 37
# specified duration (in seconds) to wait for the session handshake to complete
# a renegotiation taking longer than this has a problem, & should be aborted

mssfix 1400
# congruent with server-side --fragment directive

auth-user-pass
# passes up, via bootstrapped TLS, SHA512 hashed token value to authenticate to darknet

# auth-retry interact
# 'interact' is an experimental parameter not yet in our production build.

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3
MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOu
mLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1v
vKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaS
Tcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm
+vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QA
cOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918z
L4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npw
USWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFay
IEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/
inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtH
o6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZ
gEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjn
X03mQP3ssBs2YRNR5hR5cMdC
-----END CERTIFICATE-----
</ca>
# confirms via RSA-based public-key crypto that server instance is legitimately cryptostorm
# does NOT identify client, and is used solely as part of anti-Man In The Middle (MiTM) hardening

ns-cert-type server
# requires TLS-level confirmation of categorical state of server-side certificate for MiTM hardening.

auth SHA512
# data channel HMAC generation
# heavy processor load from this parameter, but the benefit is big gains in packet-level...
# integrity checks, & protection against packet injections / MiTM attack vectors

cipher AES-256-CBC
# data channel stream cipher methodology
# we are actively testing CBC alternatives & will deploy once well-tested...
# cipher libraries support our choice - AES-GCM is looking good currently

replay-window 128 30
# settings which determine when to throw out UDP datagrams that are out of order...
# either temporally or via sequence number

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
# implements 'perfect forward secrecy' via TLS 1.x & its ephemeral Diffie-Hellman...
# see our forum for extensive discussion of ECDHE v. DHE & tradeoffs wrt ECC curve choice
# http://ecc.cryptostorm.org

tls-client
key-method 2
# specification of entropy source to be used in initial generation of TLS keys as part of session bootstrap

# log devnull.txt
# verb 0
# mute 1
# commented out for OSX sessions as they do not play nicely with our local nomenclature syntax yet
[/code]

It does not contain the a certificate and a private key to construct the HTTPS tunnel I think... Can someone please confirm that this wel never work without cryptostorm servers to fully support SSL tunnelling?

Of course.

ovpn config:
[code]# --------------------------------------------------------
# Air VPN | https://airvpn.org | Saturday 6th of September 2014 01:50:00 PM
# OpenVPN Client Configuration
# AirVPN_NL-Nekkar_SSL-443
# --------------------------------------------------------

client
dev tun
proto tcp
remote 127.0.0.1 1413
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
verb 3
route 37.48.81.49 255.255.255.255 net_gateway
<ca>
-----BEGIN CERTIFICATE-----
[cert left out]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[cert left out]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
[private key left out]
-----END RSA PRIVATE KEY-----
</key>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
[key left out]
-----END OpenVPN Static key V1-----
</tls-auth>
[/code]

corresponding *.ssl config for stunnel:
[code]# --------------------------------------------------------
# Air VPN | https://airvpn.org | Saturday 6th of September 2014 01:50:00 PM
# STunnel Client Configuration
# AirVPN_NL-Nekkar_SSL-443
# --------------------------------------------------------

foreground = yes
pid = /tmp/stunnel4.pid
options = NO_SSLv2
client = yes
debug = 6

[openvpn]
accept = 127.0.0.1:1413
connect = 37.48.81.49:443
TIMEOUTclose = 0
[/code]

Can you post the ssl config you've been using from Air? That might help narrow down what's going on here, topologically. I'm sure others will have additional questions and suggestions, but that's the first thing that comes to my mind.

Cheers,

[i][list]~pj[/i][/list]

Hi,

Currently I'm using AirVPN's SSL tunnel (using stunnel) option to tunnel all my traffic through an OpenVPN connection masked as an HTTPS connection through port 433. This because I need to bypass a DPI firewall that only supports HTTPS through port 433. All other ports are blocked and VPN protocols through 433 are getting blocked as well.

I'm using stunnel with an .ssl config file provided by AirVPN. I'd like to move to cryptostorm, but with the general setup, it does not work.

Using OSX, Viscosity, used [url=https://cryptostorm.org/viewtopic.php?f=37&t=4135]this thread[/url] to set up and get the ovpn config.

Currently it gets blocked. Any instructions on getting cryptostorm to work wrapped in an SSL layer are welcome :)

Thanks in advance!