http://www.exim.org/bugzilla/show_bug.cgi?id=390
ph10@hermes.cam.ac.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From ph10@hermes.cam.ac.uk 2006-09-14 15:56 -------
> The issue reported to the Debian BTS in #387448 is that exim currently can be
> DoSsed by opening multiple SMTP connections and issueing STARTTLS commands
> there. In that situation, exim blocks and waits for more entropy.
This problem was addressed some time ago by allowing the parameters to be
generated externally to Exim. This is all documented in section 38.3 of the Exim
manual, which tells you how to generate the parameters outside of Exim, thus
avoiding the possibility of stalling Exim.
> In the opinion of the bug reporter, exim should not block but instead issue a
> temporary failure to allow the remote side to continue without encryption.
I do not believe this is possible. If Exim has no parameters, it calls a GnuTLS
function to generate them; the function doesn't return until it has done so, by
which time the delay has happened.
> Personally, I do not fully agree with the reporter here, but I have to forward
> the issue upstream anyway. It would probably be an acceptable option to have
> exim's behavior configurable in this regard, allowing the local admin to > >
choose
> whether to block or to issue a temp failure.
I am not a GnuTLS expert, but I do not think this is possible.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
ph10@hermes.cam.ac.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From ph10@hermes.cam.ac.uk 2006-09-14 15:56 -------
> The issue reported to the Debian BTS in #387448 is that exim currently can be
> DoSsed by opening multiple SMTP connections and issueing STARTTLS commands
> there. In that situation, exim blocks and waits for more entropy.
This problem was addressed some time ago by allowing the parameters to be
generated externally to Exim. This is all documented in section 38.3 of the Exim
manual, which tells you how to generate the parameters outside of Exim, thus
avoiding the possibility of stalling Exim.
> In the opinion of the bug reporter, exim should not block but instead issue a
> temporary failure to allow the remote side to continue without encryption.
I do not believe this is possible. If Exim has no parameters, it calls a GnuTLS
function to generate them; the function doesn't return until it has done so, by
which time the delay has happened.
> Personally, I do not fully agree with the reporter here, but I have to forward
> the issue upstream anyway. It would probably be an acceptable option to have
> exim's behavior configurable in this regard, allowing the local admin to > >
choose
> whether to block or to issue a temp failure.
I am not a GnuTLS expert, but I do not think this is possible.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##