Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Anope and SSL  (Read 16109 times)

0 Members and 1 Guest are viewing this topic.

topdog

  • Guest
Anope and SSL
« on: July 01, 2006, 12:05:52 AM »

Hello,

I'm having my network use SSL for link trafic. Does anope support SSL? Or for the services link what would you  recommend?
Logged

Charles Kingsley

  • Contributor
  • *
  • Offline Offline
  • Posts: 1405
(No subject)
« Reply #1 on: July 01, 2006, 12:13:26 AM »

No, anope doesn't support SSL. If you link your services to the ircd on the same box, you would see no benefit of using SSL. If you link services across the internet, you may wish to look at SSH tunnelling or something but I don't recommend linking services across the internet as its more likely to suffer drop outs etc than a local connection would.
Logged

topdog

  • Guest
(No subject)
« Reply #2 on: July 01, 2006, 12:24:27 AM »

wasn't planning to link across the internet, would rather link on the same box.
I was thinking of having services link on 7000 (without SSL), and actual servers link on another port (with ssl enabled).
Logged

katsklaw

  • Guest
(No subject)
« Reply #3 on: July 01, 2006, 02:02:04 AM »

I'd like to elaborate on this issue for anyone (not just topdog) wanting to know about SSL and services or even SSL in general.

When you link to localhost or 127.0.0.1 there is no outbound traffic. Localhost is a software interface and all traffic from the ircd to services is done by the OS so wanting SSL or ziplinks is moot since there is no bandwidth to save or secure. The data between services and the ircd never get to any hardware interface until the ircd is ready to send it to the network in which case you would want to use ssl and/or ziplinks between ircds.

On a slightly unrelated topic since we are not talking about Services, but we are still talking about SSL. If SSL is used it's an all or nothing thing. What I mean by that is SSL must be used from client to client in order to useful. That means that a clients connection to their ircd would need to be SSL and then the server to server connection would too .. as well as from server to client at the other end. If any of the links inbetween are not SSL, then it's pointless because there is a point in which data is transmitted in plain text which defeats the purpose of SSL. So to truely benefit from SSL there should be no clients on non-ssl connections. Most people do not understand this and think that because their ircd has SSL that their data is safe and it is not.
Logged

sdamon

  • Anope User
  • Offline Offline
  • Posts: 15
(No subject)
« Reply #4 on: August 15, 2006, 09:54:27 PM »

it provides point to point security for the client however.  single connection sll is good in situations where the client is on a lan, and the server is out in the cloud.  If the client wishes to hide the data being transmited from only local users (as i do) then taht single ssl connection is sufficent.

Aditionaly, unreal has this nice little chanmode +z which only allows ssl'ed connections to join that channel.  this doesnt help if you need secure communications and the ircd links are I.T.C... but server links are less likely to be sniffed.

on a side note:  most shell providers frown on binding to localhost.  binding to the same ip as the ircd however, still dosnt send any data out into the world.  depending on os config (iirc) though, users on the same collision domain may still be able to sniff data.  can someone else confirm or deny that
Logged

katsklaw

  • Guest
(No subject)
« Reply #5 on: August 15, 2006, 10:44:26 PM »

With shell providers, you can't really bind to localhost .. that's true. However those same users also share the same interface and have just as much access to it as you would. Meaning they can sniff the IPs on it.

IRC software was never really intended to be on shared resources, such as shell providers as it's commonly practiced today. In the event that you cannot use localhost, then the next best solution is to use stunnel for secured data transferance. Another even easier and less resource intensive solution is to use MD5 encrypted passwords and forego the usage of GETPASS and SENDPASS. SA"s can use saset in order to change a users password. Other than passwords, there is no other data that is would be sensitive enough to be of use if data is sniffed/intercepted. Yes, this adds a little workload to your staff but well worth it since you are not sending passwords in plain text over the internet regardless of the box's setup.

In short, if you can't use localhost, use MD5 encrypted passwords since it doesn't use as much resources as any other form of data encryption .. including ssl even with zip.

For those that are about to ask how you insure you set a password for the right person, you simply ask them for the email address nickserv has on file, send a quick email to that address containing completely unrelated contents, then have them paste the body of the email back to you in private message.
Logged

Jobe

  • Contributor
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1023
    • Anope IRC Services
(No subject)
« Reply #6 on: August 16, 2006, 12:00:55 PM »

Last time i checked passwords, even if encrypted in Anope's databases will STILL be transevered in plain text due to the nature of the IRC protocol. The reason i say this is because how i read your post you're saying that if you use encrypted passwords in Anope then they won't be able to be sniffed over the net which is as far as i know inaccurate.

If you follow the path of a message to identify to NickServ there is at least one point it will be in plain text and sniffable if youre using a shell.

The point is if you cant use localhost to connect Anope to the password will STILL be sniffable in plain text on its way to Anope whether it's encrypted in the database or not.
Logged
Your IP: ()
My IRC Status:

Come along and visit http://www.anopequotes.org/

Dave Robson

  • Team
  • *
  • Offline Offline
  • Posts: 357
(No subject)
« Reply #7 on: August 16, 2006, 04:30:03 PM »

Your right, even with md5 the passwords are still sent in plain text, the only advantage to md5 is if someone steal's your db's, they cant (easily) extract all the passwords from them.

The only way (that i know of) which would allow "secure" password auth with nickserv over the internet would be the ns_challenge module and a challenge/response auth.
Logged

katsklaw

  • Guest
(No subject)
« Reply #8 on: August 17, 2006, 01:20:33 AM »

Yeah, sorry .. I was suffering from a blonde moment on the md5 statement. What's worse is that I know better since understanding how networks and data streams flow is one of my strong points .. go figure. ;/

Sorry again for any confusion.
Logged

Sakkath

  • Guest
(No subject)
« Reply #9 on: December 08, 2006, 01:20:08 PM »

Well, I was referred here from a relevant SSL topic saying why we don't '/need/' SSL, yet I'm setting pretty good arguments as to how it could be useful, compile time feat. or whatnot.  If you use md5, disregarding whether we are safe or not with it at the moment, can you use MySQL?
Logged

katsklaw

  • Guest
(No subject)
« Reply #10 on: June 13, 2007, 02:53:35 AM »

yes md5 can be used in conjunction with MySQL
Logged
Pages: [1]   Go Up