[atlas] HTTP/HTTPS probe
- Previous message (by thread): [atlas] HTTP/HTTPS probe
- Next message (by thread): [atlas] HTTP/HTTPS probe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
daniel.karrenberg at ripe.net
Fri Nov 22 12:53:01 CET 2013
I suggest to start making HEAD requests to a limited set of destinations available to all users. Initially limit the list destinations under control of RIPE NCC, including anchors. I feel that this would not require an opt-in question to probe hosts, just information. As a next step we could then define a process for adding other destinations. This would prevent Atlas from becoming a general purpose tool for HTTP performance measurement and abuse. How's that to start with? Daniel On 22.11.2013, at 12:32 , Robert Kisteleki <robert at ripe.net> wrote: > On 2013.11.21. 20:41, Richard Barnes wrote: >> I think HEAD would probably be OK. At least, I'm not aware of any exploits >> that would enable. >> >> --Richard > > A completely different dimension of this is something that's (almost) unique > to Atlas: you can use vantage points that are in others' networks or homes. > Seemingly the request (whether it's GET or HEAD) will come from there. > > If one uses this to access illegal content (for whatever definition of > illegal), then the host will be in trouble, and I don't think explanations > about "it was not me, it was someone else" or "it was just a HEAD request, I > didn't really see that picture" will make a difference in all cases. (We > will likely be able to trace back the actual request to someone, but it may > not help the host in question.) > > Maybe I'm a pessimist here, but if I'm not, then it means we can only use > some kind of opt-in method, and even that does not solve the root problem. > > The alternative is to limit the potential destinations system-wide, which > severely limits the usefulness of such measurements (or it boosts the Atlas > Anchor deployment rate ;-) > > Robert > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20131122/9de72f0d/attachment.sig>
- Previous message (by thread): [atlas] HTTP/HTTPS probe
- Next message (by thread): [atlas] HTTP/HTTPS probe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]