Olá a todos,
Esta é uma semana triste para a Europa. A censura voltou a nossa casa, vestindo a capa do artigo 13, 11, etc.
Se não sabem já o que é, tem provavelmente estado a viver em alguma colónia no espaço, ou debaixo de uma pedra, mas é mau. Muito mau mesmo, especialmente por impacta diretamente o pequeno content provider and producer, a favor dos mega grupos de copyright cartelizando por completo a nossa liberdade.
Caso queiram ler mais sobre o tema, aqui está um link sobre o assunto:
https://www.wired.co.uk/article/what-is-article-13-article-11-european-directive-on-copyright-explained-meme-ban
Caso queiram um TL:DR; deixo um resumo que diz tudo de um amigo meu, o Jaime:
Para o comum utilizador, ele vai ver mais avisos de conteúdo bloqueado, terá menos acesso a noticias e será mais difícil confirmar a veracidade das notícias.
Indiretamente, os nossos artistas ficarão mais agarrados às SPAs desta terra, terão mais dificuldade em fazer frente aos gigantes Americanos e, genericamente, haverá menos cultura.
Mais insidioso, haverá menos cooperação entre as faculdades e centros de investigação e as empresas contribuindo para o aumento do desemprego e tornando a Europa menos competitiva face aos EUA e à China.
Tecnicamente, e desde a votação, tem se notado algumas alterações nos comportamentos das API’s da Google/Youtube/Facebook, mas o primeiro impacto efetivo que vi, foi partilhado pelo meu amigo meu Luís, quando colocou no seu perfil de Facebook esta imagem – alerto que existe a possibilidade de ser um mockup construido – mas o resultado final será sempre este:
Sim, estão a ler bem: “This comment has been censored due to European Union’s copyright law”.
Aparentemente, e isto é apenas uma suspeita minha, este comentário substituto, é gerado analisando por palavras chave / registos já carregados previamente (por quem ?) e em seguida cruzados com a localização geográfica de cada um (neste caso o poster), ou por IP ou por localização de GPS do equipamento que se esteja a utilizar de uma forma totalmente automática, através de filtros.
Ou seja, a probabilidade é, que na altura em que se faça o post, se algum termo for utilizado que estiver listado algures, cruzando o mesmo com o IP de origem, rapidamente se chega à localização geográfica europeia aproximada do poster, e a API do Facebook/content provider substitua o texto por aquela beleza ortográfica ou simplesmente apague o comentário / artigo.
Existe ainda a possibilidade que os comentários ao post inicial, sejam filtrados para leitura precisamente da mesma forma: Localização do leitor cruzada com termos = Censura.
Este comportamento está a ser observado igualmente no Youtube e em outros sites, pelo que suspeito que existam neste momento youtubers a estudar a possibilidade técnica de se registarem e fazerem os seus uploads desde países onde o artigo 13 não os penalize.
Então o que podemos fazer tecnicamente até a altura de votar para mudar a lei?
Ou comprar uma VPN paga (existem varias tanto para telemóveis como para desktops) e ir a redes sociais e sites como se estivesse num pais onde isto não se verifica, ou em alternativa ser criativo.
Foi nessa altura que decidi fazer este PoC para mostrar como isto é tecnicamente possível.
Nota: Este *não* é um post a promover como furar a directiva da UE, ou como se envolver em negócios menos lícitos. É apenas um PoC e o que fazem dele é da vossa exclusiva responsabilidade.
Em primeiro lugar, e usando um tcpdump, validei todos os FQDN’s que eram utilizados quando se abria o site do facebook, se procedia ao login e as aplicações satélite como o messenger.
Admito que não fiz testes intensivos, mas o que encontrei foram chamadas aos seguintes sites:
0-edge-chat.facebook.com 1-edge-chat.facebook.com 4-edge-chat.facebook.com 5-edge-chat.facebook.com 6-edge-chat.facebook.com edge-chat.facebook.com facebook.com pixel.facebook.com staticxx.facebook.com www.facebook.com
Fazendo nslookup a todos eles, descobri que cá em Portugal, pelo menos no operador MEO, todos eles resolvem para IP’s na range 31.13.83.0/24 ou ao intervalo 185.60.216.0/24 a 185.60.219.0/24
inetnum: 31.13.83.0 - 31.13.83.255 netname: MAD1 descr: Facebook country: ES admin-c: RD4299-RIPE tech-c: RD4299-RIPE status: ASSIGNED PA mnt-by: fb-neteng mnt-lower: fb-neteng mnt-routes: fb-neteng created: 2014-06-11T18:56:59Z last-modified: 2014-06-11T18:56:59Z source: RIPE role: RIPE DBM address: 1601 Willow Rd. address: Menlo Park, CA, 94025 admin-c: PH4972-RIPE tech-c: PH4972-RIPE nic-hdl: RD4299-RIPE mnt-by: fb-neteng created: 2011-04-11T18:49:50Z last-modified: 2013-08-14T15:49:58Z source: RIPE # Filtered abuse-mailbox: [email protected]
Em seguida, e utilizando para tal uma VPS que tenho acesso na OVH e que se liga ao meu homelab por VPN, configurei um privoxy para responder a pedidos com destino ao Facebook.
Nesta altura as opções técnicas divergem, especialmente por incompatibilidade (ou minha incapacidade de colocar a funcionar) (d)o método de connect, o ssl-bump e o cache_peer.
A primeira hipotese e caso se efetue sem NAT transparente ao nível da rede (que permite agarrar todo o tráfego com destino ao facebook e encaminhar ele para o proxy remoto, saindo assim do outro lado), serão necessárias as configurações ao nível do vosso squid que serve a vossa rede:
cache_peer 10.0.1.4 parent 8119 7 no-query no-digest no-netdb-exchange cache_peer_domain 10.0.1.4 .facebook.com neighbor_type_domain 10.0.1.4 parent .facebook.com acl facebook-servers dstdomain .facebook.com never_direct allow facebook-servers
Sendo que o 10.0.1.4, port 8119 é o meu privoxy de saída.
Este tipo de configuração funciona muito bem, mas irá obrigar aos vossos pcs e equipamentos terem configurado o vosso squid proxy.
A segunda hipótese, usando um proxy SSL transparente: Pode haver o caso onde não seja possível ou desejável andar a configurar proxys em todo o equipamento. Nesse caso temos a segunda opção que envolve um proxy transparente de SSL.
No vosso squid proxy efetuar (as minhas configurações são adaptadas as path’s das OPNSense):
cd /var/squid/ssl openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -extensions v3_ca -keyout proxyCA.pem -out proxyCA.pem chown squid:squid proxyCA.pem
E em seguida adicionar ao meu /usr/local/etc/squid/pre-auth/squid.user.pre_auth.conf as seguintes linhas
https_port 127.0.0.1:3131 intercept ssl-bump cert=/var/squid/ssl/proxyCA.pem dynamic_cert_mem_cache_size=10MB generate-host-certific ates=on ssl_bump server-first all # setup ssl re-cert sslcrtd_program /usr/local/libexec/squid/ssl_crtd -s /var/squid/ssl_crtd -M 4MB sslcrtd_children 5 sslproxy_cipher HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS sslproxy_options NO_TLSv1 # setup ssl bump acl's acl bump_step1 at_step SslBump1 acl bump_step2 at_step SslBump2 acl bump_step3 at_step SslBump3 acl bump_nobumpsites ssl::server_name "/usr/local/etc/squid/nobumpsites.acl" # configure bump ssl_bump peek bump_step1 all ssl_bump peek bump_step2 bump_nobumpsites ssl_bump splice bump_step3 bump_nobumpsites ssl_bump stare bump_step2 ssl_bump bump bump_step3 sslproxy_cert_error deny all
Em seguida, e para os clientes Windows e não só será necessário adicionar a CA que criaram para o squid (passo do openssl ProxyCA) aos vossos pc’s.
Para tal é necessário gerar o certificado e em seguida importar como uma trusted CA no vosso browser/computador/e-coisa.
openssl x509 -in myCA.pem -outform DER -out myCA.der
Finalmente será questão de configurarem o vosso NAT transparente para pegar na ligação com destino ao Facebook na porta 443, para que em seguida o pedido seja routeado para a vossa máquina remota via VPN e em seguida sair para a internet, fazendo que para o fornecedor de conteúdo, a vossa localização seja outro pais (recordam-se de no meu caso a saida na OVH?).
Simples como isto.
E pronto. Este post foi um rambling técnico de desagrado com tudo o que está a correr.
A nossa Europa a ficar aos poucos e poucos neste estado e este post não contempla toda a dimensão tenebrosa do tema.
Tenho dito entre dentes aos meus amigos: Vou-me lembrar disto quando for votar.
Como cidadão o nosso voto importa. É uma forma da nossa voz ser ouvida.
Caso tenham alguma duvida, ou se tiverem conseguido colocar o connect a funcionar em ssl-bump com um cache peer, já sabem onde me encontrar.
Até ao proximo post!
Um abraço!
Nuno.