The best idea PR guys from PayU might have:
Dear Sir or Madam,
We would like to apologize for the INCORRECT INFORMATION in our last communication.
During the break which will take place on 27 November 2014 from 05:00 am to 05:30 am you could not be able to log in into the system but all transactions WILL BE SETTLED. A message informing about unavailability of the service may be displayed during login attempt.
We are very sorry for the inconvenience and misrepresentation.
The funny thing is that I haven't got any e-mail on the technical break in the first place.
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:
<email@example.com> (expanded from <firstname.lastname@example.org>): host
mx.poczta.onet.pl[220.127.116.11] said: 554 5.7.1 <email@example.com>:=
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 suck 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.