3

has anyone worked with gwan server using SSL?

i have generated (self-signed) certificates in the the /cert subdirectory.

the server hung when using https:

are there any other requirements for SSL on g-wan

error.log reads

 "READ:Tmo 144 bytes:
  0: 16 03 01                                         | ...
 "READ:Tmo 87 bytes:
  0: 80 55 01 03                                      | .U..
 "
tshepang
  • 12,111
  • 21
  • 91
  • 136
Gabe Rainbow
  • 3,658
  • 4
  • 32
  • 42
  • moreover, is it necessary to have ssl on a certain port. my server is running on 9999 for the time being. – Gabe Rainbow Feb 01 '13 at 22:27
  • 1
    There's couple of newly implemented features in G-WAN that doesn't have documentation yet. Especially using protocol handlers to handle SSL. Check the timeline for more info http://gwan.ch/timeline/2012.html – Richard Heath Feb 01 '13 at 22:45
  • ok. thats bad news.i have to go back to cursed php or confusing fcgi. please noooooo. – Gabe Rainbow Feb 01 '13 at 23:43
  • SSL is mentioned in several places.? confusing. Supported HTTP features Protocols: HTTPS (SSLv2, SSLv3, TLS 1.1 + the TLS 1.2 “server_name” extension or Server Name Indication, see RFC 3546 and 4366), HTTP/0.9, HTTP/1.0, and HTTP/1.1 – Gabe Rainbow Feb 02 '13 at 00:02
  • @richard i see your other s.o. comments re "https ready but not released." thanks for the info. and man i really need ssl. i guess ill try boost asio, although tht looks insane in comparison. – Gabe Rainbow Feb 02 '13 at 00:24
  • stunnel to the rescue. thank goodness. – Gabe Rainbow Feb 02 '13 at 04:28
  • I don't think G-WAN will handle SSL natively but you can always use third party library (OpenSSL) to handle SSL. Protocol handlers will make this easier to do. – Richard Heath Feb 03 '13 at 00:59

1 Answers1

4

First, let's say how people make SSL work today: they use an SSL proxy (it is common to use hardware SSL accelerators), or SSLtunnel as a frontend.

Second, SSL was implemented natively in G-WAN a long time ago (when native AES encryption was made available), but failure to find any compliance checking tool made us delay the experimental release because SSL is a very dangerous protocol (utterly and pointlessly complex, incompatible with itself depending on versions, full of corners making room for an infinite stream of security holes).

Before you disagree with that view, have a look at the security background of OpenSSL (or at its source code, which is even more scary).

That's why keeping SSL outside of the G-WAN Core makes sense.

Third, as people asked us recurrently about hos to support SSL (and other protocols) with G-WAN, we have created Protocol handlers.

Connection handlers are used to alter the behavior of G-WAN. Unless properly used (to avoid the timeout you have hit) they will kill any non-HTTP conformant traffic. But they make people's life much easier for trivial tasks.

Content-Type handlers are used to alter the delivery of a specific type of files (GIF, HTML, FLV, etc.).

Protocol handlers are the last addition, which make G-WAN able to do anything relying on TCP/IP (UDP might be for later).

We will try to document them as soon as other, more urgent, tasks are done.

We have found that using servlets and those 3 different kinds of handlers instead one single type of modules (the generic term for other servers like Apache or Nginx), makes user-developments easier, safer, and faster.

Gil
  • 3,279
  • 1
  • 15
  • 25
  • i agree with the ssl hardware and core isolation. but here are some counter-args: 1. sticking hardware next to a virtual box at amazon, rackspace or heroku (the clear winners for the future) is virtually impossible. 2. stunnel works but it forks processes l,r and center. its basically like using apache in front of g-wan. that seems like sticking your weakest men in the front lines; and, 3. you've made g-wan super super easy to use -- in all other respects. thanks for the response, and i look forward to these handlers. – Gabe Rainbow Feb 03 '13 at 17:52