Recently new vulnerability ("poodle") has been discovered in SSLv3 protocol. "man in the middle" attack could be performed using protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 then exploit the "poodle" vulnerability.
In order to remove the threat from our servers we have to drop SSLv3 from negotiation list. Secured server should respond as follows:
$ echo | openssl s_client -connect 192.168.1.100:80 -ssl3 2>&1 | grep Secure
Secure Renegotiation IS NOT supported
$ echo | openssl s_client -connect 192.168.1.100:80 -tls1 2>&1 | grep Secure
Secure Renegotiation IS supported
We use openssl command to open HTTPS connection and check if requested protocol could be negotiated or not.
And the fix itself (for JBoss/Tomcat service): you have to locate Connector tag responsilble for HTTPS connection and:
- remove any SSL_* from ciphers attribute
- limit sslProtocols="TLSv1, TLSv1.1, TLSv1.2"
<Connector port="80" protocol="HTTP/1.1" SSLEnabled="true" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
maxThreads="100" scheme="https" secure="true" minSpareThreads="25" maxSpareThreads="50"
clientAuth="false" sslProtocols="TLSv1, TLSv1.1, TLSv1.2" />
It will effectively block any SSLv3 connections as visible by "openssl s_client" test above.
Few days ago I launched simple low-traffic mailing list using naive /etc/aliases method, but got the following error:
<firstname.lastname@example.org> (expanded from <email@example.com>): host
mx.poczta.onet.pl[126.96.36.199] said: 554 5.7.1 <firstname.lastname@example.org>:=
Recipient address rejected: Spf check: fail (in reply to RCPT TO command)
If you think for a moment the reason for error it's obvious. My server tried to forward e-mail using original From address.Onet.pl checked TXT record (using SPF standard) for my server domain myserver.com and noticed it's not allowed to send e-mails from me.
In order to make things work properly one have to rewrite envelope From field properly. Mailing list managers usually do that properly (/etc/aliases is not enough).
IPTV technology delivers video streams using fast, but not reliable protocols (UDP). Those connection-less protocols do not guarantee delivery nor retransmissions of missing packets. We have to accept low video quality for some networks or add another layer above basic protocol that allows to control completeness of delivery. For this purpose we use RTP (packet order, completeness) and RTCP (retransmission requests) protocols.
In this port I'm going to show how effectively use Linux command line tools to analyse client – server cooperation regarding retransmissions for complicated real-world example. Basic RTP metadata collected by tcpdump is used as an input.
The old truth that everyone who spends days on business trips: hotels generally sucks at local Internet delivery service. The least important service in hotel is pretty crucial if you depend on it to finish some work after business hours.
However, if you are on Linux/Ubuntu machine there's a nice tool that will allow you to evaluate WIFI signal quality. It's name is: wavemon. It's a console tool that shows current (and previous) signal strength.
Having real-time measurement you can decide what area of the hotel have the best signal strength.
I was searching for current UK VAT rates as my client operates on this marked and found the following official page that was a delight for my eyes:
Compare that with all that bloat you expect from your government and you know why some countries are much better for business than others.