mIRC Home    About    Download    Register    News    Help

Print Thread
/socklisten -e #262590 26/02/18 02:06 AM
Joined: Dec 2002
Posts: 198
T
Talon Offline OP
Vogon poet
OP Offline
Vogon poet
T
Joined: Dec 2002
Posts: 198
Would be nice if listening on a socket over SSL was supported to accompany /sockopen -e which allows connecting with a socket over SSL. Maybe even toss in something like /sslcert to be able to generate and output a self-signed ssl certificate to file.

Not sure about the command format, but I'd say: /socklisten -e <sockname> <path\to\sslcert>

Re: /socklisten -e [Re: Talon] #262592 26/02/18 05:02 AM
Joined: Aug 2016
Posts: 48
R
rockcavera Offline
Ameglian cow
Offline
Ameglian cow
R
Joined: Aug 2016
Posts: 48
I support.

The command could be: /socklisten -e <SSL_cert_file> <SSL_key_file> <name> [port]

It would certainly be very interesting.


rockcavera
#Scripts @ irc.VirtuaLife.com.br
Re: /socklisten -e [Re: Talon] #262598 26/02/18 10:57 PM
Joined: Apr 2004
Posts: 73
Z
Zelda4ever32 Offline
Babel fish
Offline
Babel fish
Z
Joined: Apr 2004
Posts: 73
I think it's a great idea to have secure listening, but this is a big can of worms. Not to mention the deprecation of SSLv3, which makes me ask, "What about STARTTLS/TLS ?"

I think if you're going to try to write an SSL/TLS/STARTTLS server, using mIRC (code) is the wrong way to go. Perhaps having robust security isn't important for this type of usage, but if that's the case then what's the point of doing this at all, especially when considering the additional complexity needed to properly implement it?


/tokenize 32 $gettok($1-,1-,32)
Re: /socklisten -e [Re: Zelda4ever32] #262602 28/02/18 12:47 AM
Joined: Dec 2002
Posts: 198
T
Talon Offline OP
Vogon poet
OP Offline
Vogon poet
T
Joined: Dec 2002
Posts: 198
all web-traffic is subject to packet sniffers and all kinda good stuff, which is why almost all websites made the move to https://, especially for logins. Also, it appears half the battles already done, /sockopen has -e to use SSL for connecting to a location securely. Looking around at using SSL in standard listening sockets in C++ doesn't look like it's a huge burden either. I just think it'd be a good addition for whatever the usage case may be to have it an option, and as for the point? Well, that sounds to me like you lost your spark smile Why does anybody code stuff in mSL? For me it's the enjoyment. To think I can, and then to prove it to myself it's possible! smile

Re: /socklisten -e [Re: Talon] #262604 28/02/18 03:10 AM
Joined: Apr 2004
Posts: 73
Z
Zelda4ever32 Offline
Babel fish
Offline
Babel fish
Z
Joined: Apr 2004
Posts: 73
It's not correct to say that HTTPS strictly uses SSL.

A secure (web) server will not support SSLv2 nor SSLv3, because these are vulnerable to attacks like POODLE and DROWN.

In the case of having a server that uses SSL and not TLS you now have the problem of vulnerabilities, web browser security warnings, and outdated cipher suites.

My point is not to discourage any coder from trying new things or to dissuade basic Internet privacy and security measures. My point is that SSL is not secure, it is deprecated by IETF for its vulnerabilities and therefore lack of security, and TLS should be used instead.

Quote:
Looking around at using SSL in standard listening sockets in C++ doesn't look like it's a huge burden either.


Writing an SSL/TLS implementation using only the standard C++ library (with Windows API) would be a massive undertaking, even if it is susceptible to vulnerabilities. There is at least one reason why Khaled is using the OpenSSL library for SSL/STARTTLS. If you think it's not a huge burden, then write your own DLL and use that for mIRC.

I can only imagine that SSL is still supported in mIRC for legacy reasons, and Khaled is working to fully implement TLS if he hasn't already put this into his plans.

So the thought for me isn't "Why not allow /socklisten for SSL," because that's out of the question. What I wonder instead is "Why not do full server/client TLS support for sockets in mIRC, since the IETF basically prohibits SSL now?"

So if you're a C++ programmer, take a look at this minimal TLS server, where OpenSSL has already done most of the work for you, but note that this code uses SSLv23_server_method(), so you should actually fix that by reading this documentation.


/tokenize 32 $gettok($1-,1-,32)
Re: /socklisten -e [Re: Zelda4ever32] #262627 03/03/18 03:39 AM
Joined: Jan 2004
Posts: 1,275
L
Loki12583 Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Jan 2004
Posts: 1,275
SSL is the colloquial catchall, obviously TLS is the intention. mIRC already has a default cipher list for connections, it can have sensible defaults for protocols and ciphers and allow the user to set them for custom sockets.

Re: /socklisten -e [Re: Zelda4ever32] #262640 04/03/18 08:49 PM
Joined: Dec 2002
Posts: 198
T
Talon Offline OP
Vogon poet
OP Offline
Vogon poet
T
Joined: Dec 2002
Posts: 198
I've used /sockopen -e on many domains on port 443 which is typical https:// and have no issues with data and communicating with a http server. Are you saying that this isn't SSL, but TLS? What's a webserver address where communicating with it with /sockopen -e would fail? I can't find an example of a https:// server that the data is garbage or connection refused using /sockopen -e, and those POODLE and DROWN attacks were addressed and fixed with new OpenSSL versions so that should be by the wayside if using a newer OpenSSL Lib.

Re: /socklisten -e [Re: Talon] #262641 04/03/18 09:30 PM
Joined: Jan 2004
Posts: 1,275
L
Loki12583 Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Jan 2004
Posts: 1,275
It's likely every site you visit uses TLS rather than SSL; you'll be hard pressed to find a production site mIRC will refuse to connect to by default. But you can set ciphers=eNULL under [ssl] in mirc.ini to watch all your connections fail.