[atlas] HTTP/HTTPS probe

I think HEAD would probably be OK.  At least, I'm not aware of any exploits
that would enable.

--Richard


On Thu, Nov 21, 2013 at 1:30 PM, Imre Szvorenyi <ax at initrd.net> wrote:

> Hi,
>
>
> HEAD would be better imho because TRACE mode is usually disabled.
> (vulnerability scanners tend to complain about it so it will be disabled
> most of the time...)
>
> ax
>
>
>
>
>
>
> On Thu, Nov 21, 2013 at 7:23 PM, Mark Delany <f4w at echo.emu.st> wrote:
>
>> On 21Nov13, Richard Barnes allegedly wrote:
>> > > GET requests should not alter state; if they do, arguably the problem
>> > > there lies with the design of the faulty website.
>> > >
>> > >
>> > Indeed, that is what the HTTP spec says. But there are a good number of
>> > fault websites out there, and it seems bad to have Atlas be a tool to
>> > exploit them.
>>
>> Agreed. Given the infinite monkeys that have written piblic facing web
>> services, there is bound to be web sites that use HTTP verbs in weird
>> and wonderful ways.
>>
>> But what about using HEAD?
>>
>> That would serve a lot of monitoring purposes as it can give you
>> connect time and time to first byte, it doesn't return any content so
>> the problem of fetching dodgy content is mitigated and the size of the
>> payload is much more constrained.
>>
>> Another alternative is to only allow something like the "OPTION" or
>> "TRACE" verbs.
>>
>> For those probing their own systems they could implement these VERBs
>> but even if those VERBS aren't implemented you still get time to first
>> byte as a consequence of the error returned.
>>
>>
>> Mark.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20131121/b3832279/attachment.html>