2016-09-18

О STARTTLS

SSL, который Secure Sockets Layer, бывает разный. И как минимум с 1999 года он называется TLS — Transport Layer Security. Впрочем, сути это не меняет.
TLS logo
Внезапно оказалось, что почти все протоколы Интернета передают ценные данные открытым текстом. И любой чувак, который сможет перехватить трафик, сможет извлечь эти ценные данные. Конечно, фоточки котиков и фильмы известного содержания — не очень-то и ценны. Но вот логин-пароль для платного доступа к котикам, или идентификатор сессии, когда логин-пароль уже введён, — уже ценны.
Поэтому придумали SSL. С точки зрения приложения — почти такой же обычный TCP сокет, вот только передаваемые данные зашифрованы. И никакой чувак посередине ваших котиков больше не увидит. Если, конечно, он не работает в правильных организациях, чьей обязанностью является бдить.
SSL/TLS — это гибридная криптосистема. У нас есть клиент, и есть сервер. Клиент всегда подключается к серверу. У сервера есть приватный ключ, который всегда при нём. И у сервера есть публичный ключ, в виде сертификата, подписанного каким-то центром сертификации. Ну или подписанный ключом самого сервера — самоподписанный сертификат. Сертификат содержит имя сервера, сведения о его владельце и прочее. Правильность этих сведений подтверждается подписью. Центры сертификации подписывают сертификаты за деньги. Это организации, которые дорожат своей репутацией, а мы им доверяем. И на этом доверии всё и держится.
Клиент, когда подключается к серверу, получает его сертификат. Он проверяет: а действительно ли это сертификат того сервера, к которому мы подключаемся? А не истёк ли срок действия сертификата? А доверяем ли мы тому центру сертификации, что подписал этот сертификат? Иногда сертификат бывает и у клиента, и он предъявляет его серверу, а сервер производит подобные же проверки. Если всё ок, то идём дальше.
Используя ассиметричное шифрование, приватные ключи и публичные ключи из сертификатов, клиент и сервер договариваются о ключе сессии. Это ключ уже симметричного шифрования. И этим ключом будут зашифрованы последующие данные. Всё секурно и красиво, если вы пользуетесь свеженькими реализациями TLS. Все SSL, версии от 1.0 до 3.0, нынче считаются небезопасными. Безопасные — это TLS 1.1 или 1.2, и, может быть, TLS 1.0.
Гибридная криптосистема
Хорошо, у нас есть надёжный способ шифровать TCP соединения. Но у нас есть и старые добрые, уже работающие протоколы. Как добавить к ним шифрование?
Поначалу решили: а давайте назовём это новым протоколом и повесим на отдельный TCP порт. К имени протокола как правило добавляют буковку S — Secure. Так HTTP стал HTTPS и переехал с порта 80 на порт 443. FTP стал FTPS, вместо портов 21-20 стал использовать порты 990-989. Не путать с SFTP, который использует шифрование SSH, а не SSL. SMTP, протокол пересылки почты, стал SMTPS и перехал с порта 25 на порт 465. В почте вообще много протоколов: POP3→POP3S — 110→995, IMAP→IMAPS — 143→993. Даже в Jabber, он же XMPP, сначала пошли по этому пути, для клиентских SSL подключений вместо порта 5222 взяли порт 5223, для междусерверных подключений вместо 5269 взяли порт 5270. О боже, даже telnets придумали, на порту 992.
Этот подход, когда для SSL шифрования выделяется отдельный порт, сам исходный протокол никак не меняется, а просто заворачивается в SSL, называется SSL wrapping. Даже была утилитка, которая так и называлась sslwrap, и позволяла добавить SSL к любому протоколу.
SSL Handshake
У такого оборачивания есть свои недостатки. У нас добавляется целый новый порт. По-хорошему, его надо регистрировать в IANA. Его надо открывать в файерволах. Этот порт должен кто-то слушать, а значит, у нас будет в два раза больше демонов: на старом незашифрованном порту, и на новом SSL порту. Наконец, так как обмен сертификатами и договорённость о параметрах шифрования происходят ещё до начала работы нашего прикладного протокола, некоторые возможности этого протокола перестают работать.
Хороший пример: виртуальный хостинг в HTTP, он перестал работать в HTTPS. У нас есть один HTTP сервер, а обслуживает он несколько сайтов, с разными доменными именами. В HTTP/1.1 клиент в каждом запросе указывает заголовок Host, куда помещает соответствующую часть URL. Сервер смотрит на этот заголовок, и выбирает, к какому обслуживаемому сайту относится запрос. Всё просто. Но в случае с SSL клиент запрашивает и проверяет сертификат сервера ещё до передачи каких-либо заголовков. И в сертификате содержится доменное имя сервера. И клиент удостоверяется что это именно то имя, к которому он обращается. По-хорошему, у каждого сайта должен быть свой сертификат. А здесь получается, что на одном 443 порту может быть только один сертификат, который не может соответствовать всем сайтам сразу. Вот и не работает.
В попытке обойти эти трудности решили пойти другим путём. Расширить протоколы, чтобы можно было начать сеанс связи без шифрования, а потом переключиться на шифрование, если и клиент, и сервер его поддерживают. Это красиво называется Opportunistic TLS. А команда, включающая шифрование, называется STARTTLS.
Сначала клиент подключается к серверу как обычно, без шифрования. В ходе начала переговоров, по правилам данного протокола, клиент и сервер выясняют свои возможности. Если и клиент, и сервер могут и хотят шифроваться, клиент посылает команду STARTTLS. После этого начинается обычная для TLS процедура обмена сертификатами и согласования ключей. Если она завершается успешно, последующие команды в сеансе между клиентом и сервером уже идут по зашифрованному каналу.
В случае SMTP это выглядит примерно так. Можно проверить обычным telnet.
% telnet smtp.gmail.com 25 
Trying 2a00:1450:4010:c02::6c...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.
220 smtp.gmail.com ESMTP d130sm3364531lfd.12 - gsmtp
EHLO localhost
250-smtp.gmail.com at your service, [2a02:2698:5425:c799:58de:766c:9bc4:25f5]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
STARTTLS
220 2.0.0 Ready to start TLS
Клиент спрашивает у сервера, какие фичи он поддерживает: командой EHLO. Сервер говорит, что, среди прочего, он умеет STARTTLS: 250-STARTTLS. Клиент говорит STARTTLS. Сервер говорит: я готов, начинай. После этого и надо начинать TLS, только telnet этого не умеет.
STARTTLS
В XMPP, так как это протокол на основе XML, STARTTLS выглядит как XML тэг: .
В OpenSSL есть встроенный клиент, который умеет делать STARTTLS. Например для SMTP.
% openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:25 
CONNECTED(00000003)
...
---
Server certificate
...
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3980 bytes and written 466 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: CE85D4D6203D288C41D56E7A6990250BBC0DADED2651335E2B0881032AA1200C
    Session-ID-ctx: 
    Master-Key: 50B893A1152F2862115396C2EB7FF43576C8D7B36D1B62F1F9E8C5ABC5293EC4DA3222674C639C146B3AA928D48537D0
    ...        
    Start Time: 1474131521
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 SMTPUTF8
Клиент довольно убогий, но оно и понятно, ибо только для тестов. Он очень забавно воспринимает некоторые символы, поэтому команды SMTP лучше набирать маленькими буквами: rcpt to:, потому что большая R заставляет этот клиент делать реконнект. Тем не менее, он умеет делать STARTTLS для smtp, pop3, imap и ftp (параметр -starttls).
Использовать один и тот же порт для незашифрованных и для шифрованных соединений оказалось так удобно, что отдельные порты для SSL быстренько объявили устаревшими. Так что теперь стандартный и кошерный способ делать TLS — это STARTTLS.
Может показаться, что это небезопасно, ведь мы начинаем сессию без шифрования. Но шифрование включается сразу же, как обе стороны решат, что оно им нужно. Открытым текстом видны только общие поддерживаемые возможности клиента и сервера. И клиент, и сервер можно настроить так, чтобы они требовали использование команды STARTTLS. В этом случае требуется, чтобы STARTTLS был одной из первых команд в сессии, до передачи важных данных. Иначе дальнейшая работа блокируется согласно протоколу.
% telnet smtp.gmail.com 25                                         
Trying 2a00:1450:4010:c08::6c...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.
220 smtp.gmail.com ESMTP w15sm2845884lff.1 - gsmtp
EHLO localhost
250-smtp.gmail.com at your service, [2a02:2698:5425:c799:58de:766c:9bc4:25f5]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
MAIL FROM: <[email protected]>
530 5.7.0 Must issue a STARTTLS command first. w15sm2845884lff.1 - gsmtp
А вот с HTTPS как-то не сложилось. Возможно, потому, что в HTTP не предусмотрено длительных сессий между клиентом и сервером, STARTTLS просто некуда воткнуть. Впрочем, подобная попытка предпринималась в RFC 2817, но не прижилась. Там предлагалось делать Upgrade протокола до TLS, примерно как сейчас делается для WebSocket или для одновременной поддержки HTTP и HTTP/2.
OpenSSLный клиент можно и для SSL wrapper использовать. (Заголовок Host для запроса в HTTP/1.1 является обязательным)
% openssl s_client -crlf -connect www.example.com:443
CONNECTED(00000003)
...
---
Server certificate
...
subject=/C=US/ST=California/L=Los Angeles/O=Internet Corporation for Assigned Names and Numbers/OU=Technology/CN=www.example.org
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3393 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: E55C3E29A1EC4A52D9BB0C18409A9AF84717DD73EED8F1F104C6751D3610DCAB
    Session-ID-ctx: 
    Master-Key: E8951CABC1DA38388F971003C668370DDA72C5D471FF87A670A7BE51D61D97851487D56B944FBBDEDE5B791632875B52
    ...
    Start Time: 1474133342
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
GET / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
...
Content-Type: text/html
Content-Length: 1270

<!doctype html>
<html>
...
Но сейчас виртуальные хостинги вполне живут под HTTPS, выкручиваются. Можно взять wildcard сертификат, на домен *.myhost.example, и все поддомены смогут прикрываться этим сертификатом. Можно включить в один сертификат несколько доменных имён, чаще всего с помощью расширения для сертификатов под названием subjectAltName. Мы просто указываем в одном сертификате доменные имена всех сайтов на нашем сервере. Вот только для добавления ещё одного сайта сертификат придётся перевыпускать.
Ну а самый кошерный способ: Server Name Indication, описанный аж в 2003 году в RFC 3546, но реально реализованный лишь в последние годы. Это расширение к самому протоколу TLS, имя сервера передаётся открытым текстом ещё до обмена сертификатами, и сервер может выбрать, какой сертификат возвращать. Полноценный аналог заголовка Host. И полноценная поддержка виртуального хостинга с разными сертификатами для разных сайтов.
SNI example
В HTTP/2 всё остаётся без существенных изменений. Спецификация не требует обязательного TLS, существуют URL со схемой http и https. Но существующие реализации работают только с TLS. При этом требуется TLS 1.2 или выше и поддержка Server Name Indication.
Тем не менее, для HTTP/2 есть забавный черновик Opportunistic Security for HTTP. Чтобы для http URL работал TLS, если клиент с сервером договорятся. Вместо одной команды STARTTLS в этом черновике предполагается обмен JSONами.

2016-09-03

О телевизоре

Мы купили телевизор. С Android TV на борту. С 4K (оно же UHD, оно же 2160p) разрешением. Производства Philips. С Ambilight.
Не то, чтобы я сильно фанател по HD. Я HD контента-то почти не видел. Хотя, конечно, появляются цифровые телеканалы. А UHD контента я не видел вообще. Но, оказалось, что UHD телевизоры лишь чуток дороже просто HD телевизоров. Производители демпингуют и продвигают новый стандарт. Ну и надо покупать, в надежде, что 4K контента будет через пару лет побольше.
С Ambilight примерно та же беда. В магазине оно смотрится потрясающе. Первую неделю после покупки вау-фактор работает вовсю. Но я уже владел несколько лет другим телевизором Philips, и знаю, что спустя две недели этот Эмбилайт вообще перестаёшь замечать. Нет, очевидный профит остаётся: телевизор вполне комфортно смотреть в полной темноте, он вполне справляется с ролью мощного ночника, освещающего полкомнаты. Но восторга уже нет.
Впрочем, в этих крайних моделях Philips последних двух лет появилась интеграция между Ambilight и Hue. Странно звучащее для русского уха название Hue — это светодиодные лампочки, которые могут менять свой цвет, и управляются через Bluetooth. Теперь ими может управлять телевизор, и освещение всей комнаты теперь может отражать происходящее на экране. Круто, наверное, но пробовать что-то не хочу.
Нынче хорошие телевизоры почти все идут с поддержкой 3D (с очками), стремятся стать тоньше, что выражается в использовании боковой (а значит, менее равномерной) подсветки, и всё такое. Мне 3D, да всякие эмбилайты с трёх сторон ну совсем не нужны. Поэтому модельку взял попроще, 6000 серии. Ну и не прогадал: по авторитетным обзорам, качество картинки у неё получше, чем у более старших собратьев. Но моделька 2016 года, вроде как у них процы помощнее, чтобы 4К видео раскодировать самостоятельно.
Ну и хотелось телевизор с Android. Я уже пользовался умнотелевизором от Philips ещё до эпохи Андроида. Видел умнотелевизоры от LG, в которых webOS. Мне, как разработчику под Android, очень хотелось пощупать Андроид и на ТВ. А умнотелевизоры с Андроидом сейчас выпускают только Sony и Philips. Sony — дорого. Так что берём Philips.
Кстати, у LG основной способ управления — перемещение указателя движениями пульта. Этакая невидимая «лазерная» указка, перемещающая указатель на экране. Имхо, это жутко неудобно, сильно точно целиться надо. В моём Филипсе всё чудовищно просто: четыре стрелки и кнопка ОК. Этим можно делать почти всё. А когда надо ввести текст, переворачиваем пульт, и имеем тугую, плохую, но вполне работающую полноценную клавиатуру. Да qwerty клавиатура расположена на обратной стороне пульта. И это в стопятьсот раз удобнее, чем тыкаться в любую наэкранную клавиатуру любым способом, кроме сенсорного экрана. Впрочем, в более старших филипсах имеется управление и жестами, и голосом, но не у меня.
Android TV оказался значительно более TV, чем Android. Собственно Андроид вылезает только в длинной начальной настройке после включения, зеленом роботе с шестерёнками в пузе при обновлении прошивки, и парочкой знакомых диалогов в некоторых глубоких найстройках. А так — телевизор телевизором. Даже включается заметно быстрее, чем умнотелевизоры пятилетней давности.
С телевизионной частью всё ок. Разъем для кабельного ТВ или обычной антенны, разъем для спутниковой антенны. Да, всякие приставки не нужны, к современным умнотелевизорам тарелку можно подключать непосредственно. Слот для CAM модуля, чтобы вам могли ограничивать доступ к цифровым каналам. Поддержка умопомрачительного набора стандартов DVB. Телетекст. Телегид, выдающий программу по вашим сотням кабельных каналов на несколько дней вперёд, через интернеты. Впрочем, сам по себе телегид, похоже, является отдельным андроидным приложением. Даже старые добрые косяки всех телевизоров Philips, когда у нас имеется штуки три разных меню, вызываемые разными кнопками, содержимое которых зависит от контекста, и одни и те же настройки могут повторяться в разных меню, вполне себе имеют место.
Нормальный такой цифровой телек. Если у нему подключить USB диск, он даже сможет записывать телевизионные передачи. Ну или делать магию с постановкой телеэфира на паузу с последующим воспроизведением.
Android TV — это не совсем Android. С точки зрения разработчика приложения для ТВ должны иметь свой отдельный GUI, оптимизированный для просмотра на большой диагонали с расстояния в несколько метров, а также работающие без тачскрина, через D-pad. Аналогично, свой GUI должны иметь приложения для часов, под Android Wear, и приложения для автомобилей, под Android Auto. Поэтому, хоть Google Play в телевизоре имеется, приложений непривычно мало. Как правило, это приложения многочисленных телеканалов и онлайн кинотеатров, те же Ivi, Tvigle и многие прочие. Ну и конечно же Netflix, который объявлен основным источником 4K контента, и которому выделена отдельная красная кнопочка в самой середине пульта. Впрочем, большинство ТВ приложений уже предустановлены.
Ещё есть игры, которые успели адаптировать под ТВ. Довольно много. И необязательно мучиться с D-pad на пульте. Официально заявлена поддержка Bluetooth и USB клавиатур, мышек и джойстиков (как минимум от Xbox).
Среди немногочисленных тестов нашлись 3DMark и AIDA64. Попугаев в 3DMark телевизор набрал раз в 5-10 меньше, чем планшет Xperia, для серьёзных 3D не очень пригоден, вероятно. AIDA64 обнаружила четырёхядерный проц, а вот разрешение экрана показала FullHD. Видимо, 4K доступен только для воспроизведения видео и только с использованием аппаратного декодера.
Ещё есть приложения от Google. И вот тут начинаешь радоваться телевизору именно с Android.
Есть Google Play Movies. Где можно купить или взять напрокат за вполне вменяемые деньги почти любые фильмы в отличном качестве. Конечно, эти фильмы никогда физически не станут вашими, смотреть их придётся онлайн. Но это дело уже привычное. Зато удобство интеграции офигенно. Покупаешь с планшета кино, заходишь в домашний экран телевизора (одна кнопка на пульте), и вот оно — кинцо, которое настоятельно надо посмотреть сейчас, ибо деньги уплачены. Впрочем, это требует, чтобы планшет и телевизор были в одном гуглоаккаунте.
Есть YouTube. Наконец-то нормальный, не тормозной, но удобный YouTube клиент для умнотелевизора. Тут можно найти UHD ролики. Вот только скорости интернетов не хватает, чтобы воспроизвести их без замираний на дозакачку. Ну и в попытке разглядеть пиксели мой взгляд спотыкается об артефакты сжатия MPEG. В общем, 4К пока доступен только на торрентах. Ну и на тестовом ролике внутри телевизора :)
С Ютубом интереснее другая фича. Приложение YouTube на планшете или телефоне унюхивает наличие телевизора, и в правом верхнем углу появляется значок Cast. Если его тыкнуть и подключиться к телевизору, то можно делать интересные вещи. Можно запустить воспроизведение видео на телевизоре. Или добавить следующее видео в очередь воспроизведения видео на телевизоре. Телефон превращается в пульт управления воспроизведением Ютуба на телевизоре.
Аналогично с Google Photos. Жмёшь Cast, листаешь фоточки, и они показываются и листаются на телевизоре.
На самом деле гуглотелевизор является полноценным Google Cast устройством, навроде Chromecast. Поэтому можно пойти дальше, и поставить на планшет приложение Google Cast. Запускаете его, подключаетесь к телевизору, и пожалуйста, весь экран планшета (и в альбомной, и в портретной ориентации) отображается на экране телевизора, и звук происходящего транслируется. Можно использовать Google Cast и в браузере Chrome на десктопе. У меня получилось транслировать вкладку браузера, даже такую в которой игрался полноэкранный флэшевый видосик. А вот трансляция всего экрана в Ubuntu что-то не заработала. Получается, вполне можно смотреть на телеке кинохи из категории «онлайн бесплатно без смс». Только вот качество страдает. Ибо сначала этот видосик, и так посредственного качества, передаётся на комп, там расжимается и воспроизводится, затем содержимое экрана снова пережимается в видеопоток, снова по локалке (бедный вайфай) передаётся на телевизор, там снова разжимается и вопроизводится. Да и батарейку ноута, если это всё проделывается на ноутбуке, это дело жрёт нещадно.
Короче, запоминайте. Скоро иконка каста станет такой же узнаваемой, как и иконка расшаривания.
Cast icon
На самом деле в этих хромкастах нет ничего нового. Эта магия называется DLNA — Digital Living Network Alliance, так же ранее известная как UPnP. Эта штука уже вполне работает на наших домашних устройствах уже лет восемь как.
В DLNA устройства самостоятельно обнаруживают друг друга в локальной сети. И выполняют они некоторые роли.
Во-первых, они могут быть Media Server. Это такой сервер, у которого под боком есть куча медиафайлов: видео, аудио, фоточки. Он их индексирует, изучает теги и каталогизирует. Ну и, соответственно, раздаёт по сети, предоставляет доступ к каталогу, даже с возможностями поиска. Медиасерверов существует великое множество. Какие-то встроены в (альтернативную) ОС. Какие-то являются отдельными демонами: MediaTomb, MiniDLNA, ... Мощные медиацентры вроде Kodi (aka XBMC) тоже содержат в своём составе медиасервер. Между делом медиасерверы ещё могут перекодировать медиапотоки в более подходящий формат, если, конечно, они запущены на достаточно мощном железе.
У меня в домашней локалке к роутеру под OpenWRT подключен терабайтный USB, и запущен MiniDLNA. В результате вся аудиовидеопомойка доступна для проигрывания.
Во-вторых, в сети встречаются Media Renderer. Это устройства, которые воспроизводят ваши видео и аудио потоки. Собственно, телевизор и является медиарендерером. Любой телевизор, выпущенный за последние восемь лет, и имеющий Ethernet порт или подключение к Wi-Fi.
В моём филипсе живут аж два рендерера. Один представляется как Google Cast Device и поддерживает весьма ограниченный набор медиаформатов, а другой является собственно телевизором производства Philips и умеет гораздо больше. А если я запущу на телевизоре Kodi (он есть под Android TV), то у меня появится ещё один убогонький рендерер. Ну и медиасервер заодно, который будет, например, расшаривать файлы с подключенного к телевизору USB диска.
В-третьих, встречаются Media Сontroller. Это штука, которая говорит: "Эй ты, рендерер, бери и играй вот этот url с этого медиасервера".
Еще выделяют Media Player, чья роль, видимо, заключается в том, чтобы порыться в каталоге медиасервера и начать проигрывать медиапоток на рендерере. Плеер уже встроен в телевизор, так что наличия медиасервера в локальной сети уже достаточно, чтобы играть с него видосики. Только искать эти видосики придётся через пульт телека.
Но можно пойти дальше и поставить на телефон или планшет потрясающий комбайн под названием BubbleUPnP. Это одновременно медиасервер, чтобы раздавать видосики и фоточки с телефона, рендерер, чтобы играть на планшете видео с домашнего медиасервера, и контроллер, чтобы порыться на медиасервере и начать воспроизводить это дело не телевизоре. В каком-то смысле это универсальный пульт управления всем DLNA хозяйством в сети. Кажется, можно его и на сам телевизор водрузить.
Кстати, о пультиках. Есть приложение-пульт от Google. Может частично заменить штатный пульт управления, если он завалялся. Заодно добавляет голосовой поиск. Есть приложение-пульт от Philips. Оно заточено под управление телевизионными функциями телека: можно смотреть расписание телепередач и переключать каналы.
DLNA медиа сервер — это хорошо. Но оно нафиг не нужно, когда на телевизор можно поставить VLC. А его можно поставить. И он играет любые файлы, какие найдет в самой обычной (SMB) локальной сети.
Современный телевизор с Android TV — штука интересная, штука крутая. Есть, конечно, кучка мелких недочётов. При вводе текста на экране появляется клавиатура, хотя есть нормальная клавиатура на пульте. Выход из меню иногда делается по стрелке влево, а иногда по клавише «назад». Вызов поиска (а для этого есть отдельная кнопочка), упорно начинает с голосового поиска, хотя у этой модели телевизора нет микрофона.
Но всё же умнотелевизор явно имеет своё место в нашем XXI веке. Это не конкурент смартфону или планшету, он их дополняет. И Android TV отлично дополняет просто Android. И пора переходить на онлайн способы потребления контента вроде Google Play Movies. Но не обязательно выкидывать накопленную видеотеку, телевизор съест и её. А кабельное телевидение, то бишь классические функции телевизора, не очень-то и нужны, вообще-то.