Hi Simon, Thanks for the rundown, that helps.
The Atlas measurement code uses something different than nc, but that isn’t really relevant, the process is roughly the same. I have a question, though. Both netcat and openssl wait for the 220 to continue. If a timeout would occur during the STARTTLS phase, or before the 220, would this differ from a conclusion perspective? In other words, is it necessary to test once for the 220 to appear (or a timeout), then another time to see if the STARTTLS completes? Could this be folded into a single test that does a 220, then the STARTTLS and will report error when there’s a fail in the process? As to the TCP traceroute, this is something used by people to measure service availability using Atlas. It isn’t something I came up with perse, but yes its to measure response time as well as availability of the service at the TCP level. With regard to additional check such as DANE, these lie somewhere between DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion. As to measurements in general, all currently support IPv6 to my knowledge. I agree that new ones should support this too. Regards, Michel > On 1 Oct 2022, at 17:11, ripe....@toppas.net wrote: > > Hi Michel, > >> 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? >> The intent of the measurement would be to validate whether an SMTP server is: >> reachable >> responsive >> capable of secured transmissions > > First, let's define the testmethod. In my opinion: > > - reachable > 3-way TCP Handshake with target on tcp/25 successful? > > - responsive > when establishing and SMTP connection, does the smtp-server signalize > readiness of the service (SMTP 220)? > > - capable of secured transmissions > when sending an EHLO, the server will tell us his features. 250-STARTTLS > should be there. > > > For all three checks, it's the easiest to use netcat. > > Reachability: >> $ nc -vz mahimahi.ripe.net 25 >> mahimahi.ripe.net [193.0.19.114] 25 (smtp) open > > Note, that we have not measured the response time. That's why you wanted to > use TCP Traceroute, right? We can also go with TCP Traceroute here. > > > Responsiveness (wait for 220): >> $ nc -C mahimahi.ripe.net 25 >> 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200 >> quit >> 221 mahimahi.ripe.net closing connection > > You might want to use the -w option here, to specify a timeout. > > > capable of secured transmissions (send EHLO and check response): >> $ nc -C mahimahi.ripe.net 25 >> 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200 >> EHLO p123456.probes.atlas.ripe.net >> 250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net [123.123.123.123] >> 250-SIZE 52428800 >> 250-8BITMIME >> 250-ETRN >> 250-PIPELINING >> 250-PIPE_CONNECT >> 250-STARTTLS >> 250 HELP > > > To check the Certificate validity and if encryption is indeed successful, we > can use OpenSSL: >> $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 > (output to long, i stripped it) > > > >> 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. > Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp > (ftps, not sftp). > > > As i said before, there are additional e-mail security features that we could > check. There's MTA-STS, where we would have to perform a combination of HTTP > and SSL check. Also, there is DANE, where we would perform a combination of > DNS and SSL check (including DNSSEC). But DANE can be used for other > protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate > check type. > > Last but no least, we should check for Forward-confirmed reverse DNS and > matching SMTP banner, which is a combination of DNS and netcat check. This > would be a reasonable part of every smtp measurement. > > > Please note, that the creator of the measurement should either specify the > exact mailserver FQDN, or the target Domain. In the latter case, an MX record > lookup has to be performed before the measurement starts, not while the > measurement is running. Otherwise it could cause credit consumption trouble, > if suddenly multiple mx records are added the domain, while the measurement > is running. > > Oh, and please make the SMTP measurement IPv6 capable :) > > > BR, > Simon > > > > On 29.09.22 11:50, Michel Stam wrote: >> 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 <mailto: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
