SSL/TLS connection - Githubissues

sj26 / mailcatcher

Catches mail and serves it through a dream.

http://mailcatcher.me

MIT License

6.31k stars 578 forks source link

SSL/TLS connection #142

Open sagikazarmark opened 10 years ago

sagikazarmark commented 10 years ago

It would be great if secure connections could also be tested.

sj26 commented 10 years ago

Agreed, this is going on the list.

ghuntley commented 9 years ago

+1 would love to see this.

chrispappas commented 9 years ago

+1 would be very useful!

styks1987 commented 9 years ago

+1 Yes, this would be very helpful.

arosenhagen commented 9 years ago

:+1:

dominh commented 7 years ago

I'm not sure if I understand. Consider a case:

Someone sniffing SSL connection. HTTP content is encrypted so he see nothing.
However he has access to TCP/IP so he can get address and port of the packet destination
he go this address and this port and get all data which was hidden by SSL So isn't SSL pointless in mailcatcher?

djmaze commented 7 years ago

@dominh Mostly. It would be a little more difficult for the man-in-the-middle if he had to guess the right hostname, in case of a SNI configuration.

This feature makes sense in combination with an additional (basic) auth protection. That could be implemented in mailcatcher as well.

But why not just run a reverse proxy (e.g. nginx) in front of it? That can be configured to do both the SSL termination and basic auth.

sj26 commented 7 years ago

This is not for HTTP, but for SMTP over TLS and STARTTLS, for testing your mail settings and libraries.

I agree that reverse proxying from nginx is better for HTTPS, and I wouldn't recommend exposing mailcatcher itself outside a development environment without something else acting as a proxy with authentication. :-)

kajmagnus commented 6 years ago

@dominh: TLS for MailCatcher is about testing only, in ones' dev env, not about real usage (to me at least).

In a prod env, TLS is required. And then it's good to be able to test, in one's dev/test env, that one's app server does work with TLS. For example, with Apache Commons Email, there're config values related to TLS, STARTTLS and SSL and port numbers, and nice to be able to verify that one's config is correct — e.g. by connecting to MailCatcher over TLS.

TomFreudenberg commented 5 years ago

Hello all,

I have added a new PR https://github.com/sj26/mailcatcher/pull/386 tonight using the MidiSmtpServer gem. It will work as expected and allows STARTTLS as well as AUTH on SMTP. All checks have been passed.

Maybe you find this helpful.

Cheers Tom

tfactor2 commented 3 years ago

Hi,

So isn't this issue a duplicate of #386?

TomFreudenberg commented 3 years ago

Hi @tfactor2

It is not a duplicate because Samuel @sj26 won't accept the PR #386 from my side (check comment: https://github.com/sj26/mailcatcher/pull/386#issuecomment-573477686)

So the issue for mailcatcher is stil open even when the PR had solved that and some other issues as well.

Nothing to wonder about - I am a bit sad about that - but it's Samuels project.

Cheers Tom

tfactor2 commented 3 years ago

Clear, thanks @TomFreudenberg,

BTW1: We decided to keep using mailcatcher despite the fact that on prod we are using TLS. To really test communication the mail server used for testing should be the same as the prod one. Out of TLS itself, there could be other things that may break, e.g. mismatch of TLS versions/ciphers. So, overcomplicating development configuration is kind of useless.

BTW2: For docker environments, I'd rather go towards standard linux smtp servers (e.g. exim4) and integrate simple webmail, see https://github.com/hauptmedia/docker-mailcatcher. It's quite trivial to add TLS there. IMHO and with all respect to the author of the project as without docker the sj26/mailcatcher it's indeed a very useful tool.