View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005735unrealircdpublic2020-08-01 21:372020-08-03 16:42
Reporterwestor Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionno change required 
Product Version5.0.6 
Summary0005735: Allow STS policy to be used only on specific ports
DescriptionHello,

I noticed today, that when someone uses STS policy and there are other ports opened the ircd automatically uses STS on these ports, example, i have set ZNC on port 6555 so when i try from the client to connect on 6555 the IRCD automatically uses STS to +6697.

So in this case i have to disable STS on the client side (mirc doesn't support it) to connect on 6555 port.

So i request one of the followings additions (probably there should be a better one but i cannot think it now).

1) A set option to skip some ports from STS policy.

Example:

set {
    ssl {
        sts-policy {
            skip-ports: "6555 5510";
            port 6697;
            duration 180d;
        }
    }
}

2) A listen block option to be able to use STS policy on that port.

listen {
    ip *;
    port 6667;
        options { allow-sts; }
}

- Thanks!
TagsNo tags attached.
3rd party modules

Activities

syzop

2020-08-02 14:17

administrator   ~0021683

I don't understand, if a client does not support STS it simply will ignore STS and keep going on using the same connection (it won't reconnect).
You are saying you needed something special for ZNC? or for mIRC? Some kind of interoperability issue?
Perhaps you can elaborate on why you need this :)

westor

2020-08-03 16:27

reporter   ~0021690

Actually i was hurry up to post that post, finally i created a new subdomain like znc.domain.here and seems to working as expected.

You can close that ticket, forget about it, it seems the wrong was mine here.

- Apologizing ... :D

syzop

2020-08-03 16:42

administrator   ~0021691

Sure, closing then :)

Also, you make a lot of useful bug reports, it's no problem at all if once in a while one or two of them are wrong :)

Issue History

Date Modified Username Field Change
2020-08-01 21:37 westor New Issue
2020-08-02 14:17 syzop Note Added: 0021683
2020-08-02 14:17 syzop Priority high => normal
2020-08-03 16:27 westor Note Added: 0021690
2020-08-03 16:42 syzop Assigned To => syzop
2020-08-03 16:42 syzop Status new => closed
2020-08-03 16:42 syzop Resolution open => no change required
2020-08-03 16:42 syzop Note Added: 0021691