Hi Simon, > >Can we achieve the first 2 items of this measurement by doing a TCP > >traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for > reachability/responsiveness of the host, but not the actual service (smtp).
That would would indeed mean a combination of TCP and SSL measurement to achieve all 3 required functions. Is it problematic if the result comes from multiple steps? If so, can you explain how? I just noticed that the SSL measurement offers a time to connect, response time, certificates as well as SSL alerts which may be leveraged, see here: https://atlas.ripe.net/docs/apis/result-format/#version-4610 <https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, although I understand it is typically used to determine service availability. > >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or > LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was > successfull. For SMTP, that doesn't work. That's because regular SMTP > communication starts first, so both sides can negotiate if SSL/TLS encryption > is possible (via Enhanced SMTP Status Codes). However, as far as i know, > OpenSSL does support SMTP and STARTTLS. So you could probably modify the > existing SSL measurement. > > Keep in mind that there's also MTA-STS and DANE, which are really enhancing > SMTPs security. A dedicated SMTP measurement would be a good thing. You’re correct, the current SSL measurement does not support any form of STARTTLS, this is something that would have to be considered for implementation. I assume, much like with SMTP, similar cases could be made for IMAP4/POP3 or XMPP. I would like to understand if there are particulars you are looking for that need to be considered outside of STARTTLS support? Regards, Michel > On 23 Sep 2022, at 17:08, ripe....@toppas.net wrote: > > Hi Michel, > > >Are we monitoring the Internet or monitoring a service using the proposed > >SMTP measurement? > First of all, we are monitoring the service of a specific target. Same as > http or ntp measurements, just another protocol. But we also monitor the > Internet. Using an SMTP measurement, we could identify censorship or discover > Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS > command). > > >Can we achieve the first 2 items of this measurement by doing a TCP > >traceroute on port 25? > I would say no. Using TCP Traceroute, you can may check for > reachability/responsiveness of the host, but not the actual service (smtp). > > >Does the SSL measurement cover the intended use cases? > I would say no. Correct me if am am wrong. Usually (for example HTTPS or > LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was > successfull. For SMTP, that doesn't work. That's because regular SMTP > communication starts first, so both sides can negotiate if SSL/TLS encryption > is possible (via Enhanced SMTP Status Codes). However, as far as i know, > OpenSSL does support SMTP and STARTTLS. So you could probably modify the > existing SSL measurement. > > Keep in mind that there's also MTA-STS and DANE, which are really enhancing > SMTPs security. A dedicated SMTP measurement would be a good thing. > > BR, > Simon > > > > On 23.09.22 16:04, Michel Stam wrote: >> Hi everyone, >> >> Great that this request sparked a good discussion on the merits of a >> measurement, as well as its potential impact on servers around the world. >> Good to see this! >> >> So I’m going to do a quick recap here, hoping that I capture the intent and >> the concerns correctly. Please correct me if I err. >> >> The intent of the measurement would be to validate whether an SMTP server is: >> reachable >> responsive >> capable of secured transmissions >> >> The concern is that such a check would trigger one of a variety of anti spam >> measures in place around the world, and/or cause undue traffic to SMTP >> server operators. >> >> With this in mind, I am wondering: >> Are we monitoring the Internet or monitoring a service using the proposed >> SMTP measurement? >> Can we achieve the first 2 items of this measurement by doing a TCP >> traceroute on port 25? >> Does the SSL measurement cover the intended use cases? >> Is it worth exploring STARTTLS support as an extension and what would the >> implications be? >> >> Have a good weekend! >> >> Best regards, >> >> Michel >> >>> On 21 Sep 2022, at 00:11, Avamander <avaman...@gmail.com >>> <mailto:avaman...@gmail.com>> wrote: >>> >>> > Making arguments based upon extreme cases, assumptions, or >>> > potential-for-collateral-damage is not scientific. "I know one that even >>> > [...]" Anecdotal evidence isn't scientific. >>> >>> From the perspective of your previous sentences that's kinda humorous. "To >>> avoid unnecessary costs incurred from disruption of service, excessive >>> traffic, annoyances using up *my* time, and countless other reasonable >>> rationale from *my* point of view." Because sure, a few (hypothetical RIPE >>> probe) connections are exactly that, zero exaggeration, right? >>> >>> In the end such fail2ban-fueled (or similar) behaviour I initially >>> addressed, is exactly a non-scientific extreme-case assumption-based >>> approach. There are better and even more standard ways. >>> >>> Crutch solutions out in the wild shouldn't be a showstopper for measuring >>> the ecosystem. (That is already quite neglected) >>> >>> > What _objective_ risk/benefit analysis are you basing your opinions upon? >>> >>> And you? What's the implication here about systems being as trigger-happy >>> as previously described? >>> >>> Because sure, at some point rate limits make total sense, but certainly not >>> at the point where it would ban any potential RIPE probes. >>> >>> > Are you a systems administrator? >>> >>> Let's not get into such measuring contests, even if it is the RIPE Atlas >>> mailing list. >>> >>> On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas >>> <ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>> wrote: >>> On 9/20/2022 10:45 AM, Avamander wrote: >>>> Great to hear it works for you, but the potential unfortunate collateral >>>> from such a blanket action is not really RIPE Atlas' problem. There are >>>> more fine-grained methods against bruteforce attempts and open relay >>>> probes, than triggering on a few connections. >>> What _objective_ risk/benefit analysis are you basing your opinions upon? >>> Are you a systems administrator? My responsibility is to avoid unnecessary >>> costs incurred from disruption of service, excessive traffic, annoyances >>> using up *my* time, and countless other reasonable rationale from *my* >>> point of view. >>> >>> You suggest that it is "not really RIPE Atlas' problem". That's very true. >>> And it is not really my problem if I bounce yoinky, pointless probes of my >>> server, and ruthlessly block them from contacting my server ever again. My >>> server, my choice, my wallet, nobody's business but my own. >>>> Some webmasters ban IP's for simply visiting a domain, I know one that >>>> even dispatches an email to your ISP's abuse@ address upon visit. Should >>>> RIPE Atlas probes then not probe any HTTP servers? The answer is obviously >>>> no, they shouldn't care. >>> Making arguments based upon extreme cases, assumptions, or >>> potential-for-collateral-damage is not scientific. "I know one that even >>> [...]" Anecdotal evidence isn't scientific. >>> >>> Note, I run a probe myself. I don't block any RIPE Atlas traffic on my >>> separate servers hosted on AWS, Oracle, and GCE. >>> >>> -- >>> Paul Theodoropoulos >>> anastrophe.com <https://www.anastrophe.com/>-- >>> ripe-atlas mailing list >>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >>> <https://lists.ripe.net/mailman/listinfo/ripe-atlas> >>> -- >>> ripe-atlas mailing list >>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >>> <https://lists.ripe.net/mailman/listinfo/ripe-atlas> >> >> >
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
