Right you are. I did just run it against OR port and it tells it
rejected early CCS. So it must be web server related problem.
Thanks!
On 06/23/2014 08:28 AM, andr...@reichster.de wrote:
...
> but you could check against different ports with the tripwire python
> script [1] to check if its a we
Yes, both Qualys and Tripwire tests are testing a web server's HTTPS port.
Yes, I do run mod_pagespeed on the web server. Alas, I get the same
result when I disable it and restart Apache. It is however an
interesting direction to investigate, since now I am thinking of
examining other modules as w
usercontent.com/Tripwire/OpenSSL-CCS-Inject-Test/master/OSSL_CCS_InjectTest.py
I would love to see if anyone else is getting the same warnings.
Thanks...
On 06/21/2014 03:09 PM, Tora Tora Tora wrote:
> And now I have tried a reboot. No change. Weird ...
And now I have tried a reboot. No change. Weird ...
On 06/20/2014 12:32 PM, cbr...@hush.com wrote:
> Agreed. I had a few other issues and went the reboot route.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cg
Yes, I tried below steps, other than 'yum ps'.
On 06/21/2014 02:00 PM, Martin Bukatovič wrote:
...
> You have probably figured this out already (you just needs to restart
> the tor daemon), but you may find the following handy (Fedora, CentOS,
> RHEL specific):
>
> To find out if your openssl p
:
>
>
> On 06/20/2014 12:47 AM, Tora Tora Tora wrote:
...
>
> Suggestion #1: upgrade to current version of your OS and apply all
> updates available for that version
>
> Suggestion #2: rebuild Tor, using the current version of OpenSSL.
Yes, restarted the applications and verified with 'lsof'
On 06/20/2014 04:12 AM, Simon Hanna wrote:
...
> Did you restart all applications that are using openssl? If not, they
> continue to use the old librariers. Best way is to just do a complete
> restart..
___
Regretfully, I have to shutdown my two middle relays (not too big, you
won't even notice it :-D), since I am unable to resolve issues with the
latest OpenSSL bug.
I was able to find upgraded packages for Centos and Fedora that are
supposed to address CVE-2014-0224 vulnerability (the change log cla
I have two relays running, both with patched up SSL, latest alpha build
and with new keys. Both are stable and guards, yet since the last
restart several days ago one transferred:
40GB -
https://atlas.torproject.org/#details/D0B1FAD2AE3C5CA526D8329D20FA55BF2BFDAF1E
and the other
2GB -
https://at
I am running a latest 0.2.5.3-alpha Tor build. This time I am observing
multiple connections within one minute established on a data port from
the same address (not sure if client or relay). The latest flood of
connections comes from One World Labs who claim to be a computer
security company that a
OK, perhaps I have missed "the how" and "which" somewhere, but which
signature am I supposed to verify the new Tor 0.2.5.3 tarball against? I
tried the ones mentioned on Tor signing page and none seem to stick. A
typical message is:
# gpg --verify tor-0.2.5.3-alpha.tar.gz{.asc,}
gpg: Signature m
On 02/28/2014 11:14 AM, Greg W wrote:
Are you suggesting that the IP's making the connections are potentially
exit nodes (they're not, I've checked) or that abuse email volume in
general should be lowered regardless of the nature? Just trying to
understand your sentiment here :)
Why not firewal
Good to know. I guess I will not shutdown underused relay just yet. A
prepaid traffic allotment would be a terrible thing to waste! :-)
...
A fine research question. A lot of the questions from
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
apply here too.
One theory is that it's a
Anyone? Several days ago, both relays had roughly the same consensus weight.
On 03/18/2014 05:02 PM, Tora Tora Tora wrote:
Declining dramatically
https://atlas.torproject.org/#details/90743CFA1B93295B9334CC0C625D22990AABA25F
vs
https://atlas.torproject.org/#details
Declining dramatically
https://atlas.torproject.org/#details/90743CFA1B93295B9334CC0C625D22990AABA25F
vs
https://atlas.torproject.org/#details/CC2F7C6ED12B67CB3882B98213E02DEF2CB82293
that is holding steady
___
tor-relays mailing list
tor-relays@list
On 03/14/2014 02:45 PM, Roger Dingledine wrote:
...
See https://trac.torproject.org/projects/tor/ticket/9969 for one case.
I wonder if these are clients running Tor versions from back before we
did directory fetches tunnelled over the ORPort -- clients from that long
ago would launch quite a f
Not sure I should disclose them in a public forum, but somewhat
obfuscated they are:
5.0.137.xx - Syria - 455 connections
66.150.6.xx - Groundspeak, Inc - 108 connections
72.78.110.xx - Verizon - 202 connections
68.101.234.xx - Cox Communications - 51 connections
etc.
It seems there were attem
On 03/13/2014 09:37 PM, Zenaan Harkness wrote:
...
I think it is unusual.
Are you just checking the tor log to see this?
OK, so I am being DOSed then.
Maybe try installing some ip blacklist or dynamic firewalling?
rblcheck is a debian package which may be relevant.
Maybe time to do some
Anyone knows the answer? It happened again with another IP establishing
400+ connections to directory port within a minute. Me thinks it was not
a good idea to display the directory port.
On 03/10/2014 01:14 PM, Tora Tora Tora wrote:
I just recently allowed the directory ports of my relay
I just recently allowed the directory ports of my relay to be listed and
noticed that some IPs are a bit overzealous in connecting to the
directory port. As in 108 connections within a minute zealous.
Is this unusual?
___
tor-relays mailing list
tor
I am pretty sure the answer is "NO", but is there a way to "enhance" Tor
in such a way that a relay that does not host hidden services can also
choose not to carry traffic for hidden services? That way those who want
to use hidden services can do so by using more limited subset of the Tor
netwo
I am testing 0.2.5.2-alpha for non-exit relay and seeing lots of
"Invalid length on ESTABLISH_RENDEZVOUS" errors. Any cause for concern?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/to
...
> Actually, what would that be good for? As long as a relay is so lightly
> loaded that the active connections each can have more than than, there
> is no point in throttling them, and as soon as there isn't, they're
> fair-share-throttled down below that anyway.
Uhm, my thought was to make T
Yes, sorry. I do know the difference between the two, but my morning
coffee was not kicking in yet, and I was definitely not paying
attention. Thanks for taking the time to point out my mistake.
On a similar subject, is there a way to limit Tor's "per connection"
speed, i.e., not total speed. Assu
I have configured Tor with the following (with daily accounting):
RelayBandwidthRate 384 KB
RelayBandwidthBurst 512 KB
I always assumed that the burst bandwidth will set the maximum relay
bandwidth. However, by using iftop, I can see individual connections
with speeds as high as 2+ Mbps. Even wh
OK, I got it. So open outgoing connections, but restrict incoming
connections to my ports, e.g, 9001 and 9030, correct?
On 02/04/2014 02:00 PM, Moritz Bartl wrote:
> On 02/04/2014 07:20 PM, Tora Tora Tora wrote:
>> Is it correct to assume that if I am running a locked-down IP address
Is it correct to assume that if I am running a locked-down IP address
behind the firewall, it means my relay would connect to a very limited
number of other relays that also run standard ports? Would that would
affect anonymity?
Also, what is the right to deal with this issue without compromising
I am trying to run a middle relay with no-exit policy. It was my
assumption that a middle relay would only communicate with other relays
on 9001 port. Yet I see my relay IP address attempting connections to
other IP address on ports that are non-9001 (or 9030).
_
28 matches
Mail list logo
