Tag Archives: 2021

Бюджет на ЕС: мерки в подкрепа на културата и творчеството

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/06/02/budg/

Брюксел, 30 май 2018 r.,  прессъобщение на ЕК

Европейската комисия предлага в следващия дългосрочен бюджет на ЕС за периода 2021—2027 г. финансирането за програма „Творческа Европа“, чрез която се подпомагат европейските сектори на културата и творчеството и аудио-визуалните произведения, да се увеличи на 1,85 млрд евро.

Предложението на Комисията за укрепване на секторите на културата и творчеството в ЕС е съсредоточено върху три области: „МЕДИА“ — направлението на програма „Творческа Европа“, чрез което се подпомагат филмовата и другите аудио-визуални индустрии на ЕС, „Култура“ и междусекторни действия:

1. „МЕДИА“: с 1,081 милиарда евро ще се финансират аудио-визуални проекти и ще се стимулира конкурентоспособността на европейския аудио-визуален сектор. Програма „МЕДИА“ ще продължи да подпомага развитието, разпространението и популяризирането на европейски филми, телевизионни програми и видеоигри. През следващите години ще бъдат инвестирани повече средства в рекламата и разпространението на европейски произведения на международно равнище и в новаторските подходи при разказването на истории, включително виртуалната реалност. Ще бъде създадена онлайн директория на филми от ЕС, за да се увеличат достъпността и видимостта на европейските произведения. 

2. Направление „КУЛТУРА“: 609 милиона евро от новия бюджет ще бъдат предназначени за насърчаване на европейските сектори на културата и творчеството. Ще бъдат създадени проекти за сътрудничество, мрежи и платформи, които ще свързват талантливите хора на изкуството от цяла Европа и ще улесняват трансграничното сътрудничество между творците. 

3. ОБЩИ ДЕЙСТВИЯ В СЕКТОРИТЕ НА КУЛТУРАТА И МЕДИИТЕ: със 160 милиона евро ще се финансират МСП и други организации, работещи в секторите на културата и творчеството. Средствата ще се използват и за насърчаване на сътрудничеството в областта на културната политика в целия ЕС , свободата, разнообразието и плурализма на медийната среда, а също и за подпомагане на качествената журналистика и медийната грамотност.

Законодателно предложение и информационен документ

Медийна свобода и плурализъм

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/17/sofia_16052018/

В София се проведе международна  конференция “Медийна свобода и плурализъм: Как да рестартираме основния стълб на ЕС“.

Записи от   конференцията могат да се видят тук:  сесия  I and   сесия II) или тук.

Пълният текст на заключителната декларация, в края са  препоръките:

Свобода на медиите в Европа: Код червено

През 1997 г. Софийската декларация на ЮНЕСКО за свободни и плуралистични медии бе ревностен призив за напредък в контекста, в който появата на нови информационни и комуникационни технологии се считаше за нова възможност за плурализъм, икономическо и социално развитие, демокрация и мир. Сега, 21 години по-късно, независимите медии в Европа претърпяха безпрецедентен натиск. Комбинацията от различни фактори, като убийствата на журналисти и физическите заплахи срещу тях, нарастващия политически и институционален натиск, репресивното законодателство, насочено към медиите, разрушителните технологии и финансовата криза, поставят съществуването на свободните медии в редица европейски страни в риск.

Свободният достъп до разнообразна информация и мнение е не само основно право на човека, но е от съществено значение за гражданите да участват в демократичното общество. Това е основната рамка, позволяваща на хората да държат отговорни представителите на властта, за да се ограничат престъпността и корупцията, което е ключов фактор за осигуряване на функционираща демокрация.

Създаването на контролирани медии е първата стъпка към моделите на публично управление, известни като “меки диктатури” или “завладяна държава”, което създава сериозни заплахи за нормалното функциониране на демокрацията не само за съответните държави, но и за целия Европейски съюз.

Неотдавнашните събития в някои от държавите-членки на ЕС очевидно нарушават националното и международното право, когато става въпрос за защита на медийната свобода, а именно Всеобщата декларация за правата на човека, Международния пакт за граждански и политически права, Европейската конвенция за правата на човека и Хартата на основните права на Европейския съюз (ЕС). ЕС и Съветът на Европа създадоха правни процедури за защита на свободата на изразяване в Съда на Европейския съюз и Европейския съд по правата на човека. Въпреки това тези структури понякога не са достатъчни, за да поддържат и наложат основните европейски ценности и конституционните си традиции.

Бюджет на ЕС и върховенство на закона

На 2 май 2018 г. Европейската комисия предложи бюджет за периода 2021-2027 г. и изготви стратегически план за наказване на страни, за които твърди, че са нарушили основните ценности на ЕС. Планът обвързва финансирането от Европейския съюз с принципите на правовата държава, но е твърде ограничен и не споменава свободата на медиите.

Комисията предлага нов механизъм за защита на бюджета на ЕС от финансовите рискове, свързани с общите недостатъци на правовата държава в държавите-членки. Новите инструменти биха позволили на Съюза да преустанови, намали или ограничи достъпа до финансиране от ЕС по начин, който е в съответствие с вида, тежестта и обхвата на недостатъците на правовия ред. Такова решение ще бъде предложено от Комисията и ще бъде прието от Съвета чрез гласуване с квалифицирано мнозинство, което ще направи невъзможно една или две държави да блокират наказателните мерки.

Предложението се очакваше и беше направено в отговор на Полша, първата и единствена страна, която досега е обект на механизма на върховенството на закона, тъй като ЕК установи системно поведение, поставящо демокрацията в опасност. Унгария също е на радара на Комисията, където демократичните условия се влошиха, след като продължителни усилия за институционализиране на “нелибералната демокрация” в страната. Полша и България, председателстваща Съвета на ЕС, бяха сред първите държави, които реагираха отрицателно на предложения нов регламент.

Убийства и физически заплахи

Ерозията на европейския демократичен модел, тенденция, наблюдавана през последните години, продължава и става все по-тревожна. Регионът е разтърсен от две убийства и от заплахи към разследващи репортери, както и безпрецедентни вербални атаки срещу медиите. Традиционно безопасната среда за журналисти в Европа започна да се влошава. Две убийства за пет месеца, първото в Малта и второто в Словакия, показват тревожен спад за демокрациите на континента. В Малта, смъртта на журналистката и блогър Дафне Каруана Галиция, в следствие на умишлено поставена бомба в колата ѝ, повдигна завесата на съдебния тормоз и заплахи, на които постоянно са подложени журналисти от островната държава.

Каруана Галиция е била заплашвана от години и е била обект на 42 граждански и пет наказателни дела. Словакия все още е разтърсена от убийството на 27-годишния репортер, разследващ корупцията и мафията. През април италианските правоохранителни органи осуетиха подготвяното от мафията убийство на журналиста Паоло Боромети.

Икономическа устойчивост

Независимостта на медиите и свободната журналистика е възможна само ако медийните компании са икономически независими и финансово устойчиви. През 21 век издателите на печатни медии остават основните инвеститори в журналистическо съдържание и са увеличили усилия и инвестиции, за да предложат най-новите иновативни дигитални услуги за читателите в Европа и в останалата част на света. Тези постижения се оказват плодотворни, тъй като вестникарските публикации достигат до безпрецедентно висок брой читатели. Този успех само потвърждава, че бъдещето на пресата е не само дигитално, но и пълно с възможности за разширяване на читателския интерес към публикациите на вестници и списания.

За съжаление, през последното десетилетие значителна част от икономическата база на независимите медии е ерозирала. Медийните компании изпитаха двоен шок от кризата в бизнес цикъла и бизнес модела си.

Възстановяването от глобалната финансова криза в Европа беше твърде бавно и твърде скъпо и съвпадна с кризата в медийния бизнес модел. Също така, появата на дигитални платформи и глобални дигитални гиганти като Google и Facebook засили неравнопоставеността между посредниците и инвеститорите и създателите на съдържание, а именно издателите. Въпреки нарастващото търсене на новини и коментари, осигуряването на приходи от такова съдържание се оказва предизвикателство, тъй като авторското право и законите за ДДС от периода преди въвеждането на дигиталните технологии не могат да защитят инвестициите и пазарния дял, както и широкият достъп до онлайн съдържание предоставят на основните платформи лъвския дял от рекламните приходи.

Данните на Бюрото за интерактивна реклама от 2016 г. показват, че 89% от разходите за онлайн реклама са отишли за Google и Facebook, като останалите 11% са за всички останали дигитални играчи.
Много предложения на ЕС, свързани с дигиталната сфера, заплашват с тежки и несправедливи съдебни и административни процедури. Като например предложения за електронна конфиденциалност, които биха дали преимущество на най-силните технологични играчи и биха въпрепятствали по-малките играчи, които са зависими от «бисквитки» и от сложно сътрудничество с трети страни, за да бъдат част от икономиката на данни.

В много страни от ЕС икономическите трудности, които медийните компании са преживели, доведоха директно до концентрация на политически контрол над медиите и засилена зависимост от правителственото финансиране. В някои случаи управляващите политически елити използват средства на правителството и ЕС, за да подкрепят лоялните медии и да манипулират общественото мнение. В тези страни обществената телевизия и радио също са загубили независимост или са под нарастващ политически натиск. На практика тези процеси доведоха до това, че големи части от медийния пазар минаха под контрола на управляващите политици и техните поддръжници за целите на пропагандата, като същевременно предприеха тежки атаки срещу малкото останали независими медии. Близо сме до карйната «цел» за безотчетна власт в някои от страните в ЕС.

Код червено за медийната свобода в държави в Европейския съюз

Полша

Изглежда нищо не е в състояние да спре “Право и справедливост”, национално-консервативната партия, спечелила изборите през октомври 2015 г., която се стреми към радикално реформиране на Полша, както сметне за подходящо, без да зачита онези, които мислят по различен начин. Свободата на медиите е една от основните жертви на техния проект. Обществените медии официално са преименувани на “национални медии” и са преобразувани в говорители на правителствената пропаганда. Техните нови ръководители не търпят нито опозиция, нито неутралност от страна на служителите и отстраняват онези, които отказват да се съобразят.

Разследващият журналист Томаш Пиатек беше заплашен с лишаване от свобода заради критиките, отправени към министъра на отбраната относно връзките му с руските разузнавателни служби и трябваше да изчака много месеци преди обвиненията да бъдат окончателно оттеглени. Съветът за радио и телевизия, който сега е под контрола на правителството, се опита да наложи глоба на частния телевизионен канал TVN за излъчване на антиправителствени послания при отразяването на вълна от протести през декември 2016 г. Впоследствие глобата беше отменена под международен натиск. На всички призиви за умереност правителството отговаря с познатите аргументи, нетърпящи несъгласие.

Унгария

Бизнесмените, които са в тесни връзки с партия «Фидес» на премиера Виктор Орбан, не само успяха да придобият нови медии през 2017 г., но и да заместят чуждестранните медийни компании, инвестирали в унгарски медии. Най-големият им успех бе поемането на контрол над последните три регионални ежедневника. Независимо от това, унгарският медиен пейзаж все още е разнообразен и печатни и онлайн издания не се колебаят да публикуват разследвания за предполагаема корупция, включваща най-влиятелните личности от Фидес и държавни служители. В Унгария съжителстват два типа медии. Единият се състои от проправителствени и про-Фидес медии, обсебени от темата за миграцията, “защитата на Унгария и нейните граници” и очернящата кампания срещу унгарско-американския милиардер филантроп Джордж Сорос.

Другият тип медии са насочени към разкриване на корупционни скандали. Оцеляването на медиите, критикуващи правителството, се дължи до голяма степен на бившия съратник на Орбан Лайош Симичка, който през февруари 2015 г. се разграничи публично от премиера и продължава да финансира медийна империя, създадена първоначално за подкрепа на Фидес. Правителството и неговите бизнес съюзници вече са се наточили на две медии – най-големият търговски канал RTL Klub и водещият политически информационен сайт Index.hu. И двете критикуват правителството.

България

През изминалите години свободата на медиите в България се влошава с тревожни темпове. Според световния индекс за свободата на медиите на Репортери без граници, България се е смъкнала със 75 позиции през последните 12 години – от 36-та през 2006 г. до 111-то през 2018 г. Налице е нарастващ политически натиск и нарастващ брой физически заплахи срещу разследващи журналисти, издатели и независими медии. Основният инструмент за упражняване на натиск е концентрацията на собственост върху медиите, икономическите зависимости и други форми на политически контрол върху по-голямата част от медийното пространство и монопол върху каналите за разпространение на медийно съдържание. Моделът включва също така силно влияние върху правителството, прокуратурата и съдебната власт, както и контрол над повечето независими регулатори. Всичко това представлява огромен политически и бизнес конгломерат, ръководен от действащия политик, бивш магистрат, бизснесмен и медиен собственик Делян Славчев Пеевски.

От 2009 г., с кратки прекъсвания, България е управлявана от ГЕРБ и техния лидер и премиер с три мандата – Бойко Борисов, който се радва на комфорт от страна на контролираните от Пеевски медии. Премиерът Борисов не само постоянно отказва да признае, че съществува заплаха за свободата на медиите, но играе ключова роля за увеличаване на достъпа на г-н Пеевски до публични ресурси, като същевременно му предоставя допълнителни институционални инструменти за репресия, включително законодателни решения, използвани срещу независимите медии.

Малта

2017-та бе белязана от бомбения атентат срещу Дафне Каруана Галиция, разследваща журналистка, която бе разкрила “мръсните тайни” на местната политика и косвено предизвика предсрочни общи избори през юни 2017 г. Години наред тя е била под нарастващ натиск заради популярността на нейния блог и работата ѝ по разплитане на местните връзки от т.нар. Досиета Панама и т.н. Към момента на убийството ѝ срещу нея вече са били заведени 42 граждански иска и пет наказателни дела за клевета. Тя също бе постоянен обект на заплахи и други форми на тормоз. Съдебният тормоз имаше за цел да я отстрани от обществения живот. Нейният случай беше класически пример за съдебни дела, в които влиятелни ищци се опитват да използват страха от огромни разходи за правна защита, за да затворят устата на критиците си. Под заплаха от страна на известни личности или бизнес групи, независимите медии са принуждавани да отстъпят и да премахнат публикации от своите сайтове.

Словакия

Убийството на разследващия репортер Ян Куцяк през февруари 2018 г. предизвика безпрецедентен политически трус в Словакия и стресна международната общност. Куцяк провеждаше разследване за уебсайта Aktuality.sk относно предполагаеми връзки между италианската мафия и Smer-SD (ляво-популистката партия, която оглавява управляващата коалиция) и предполагаемото присвояване на средства от ЕС. В недовършена статия, публикувана след смъртта му, той обвинява премиера Роберт Фицо в пряко участие.

Министрите на културата и вътрешните работи бяха принудени да подадат оставка и след големи улични протести, самият Фицо трябваше да последва примера им. Подобно на други словашки политици, Фицо бе подложен на засилени атаки в медиите. През ноември 2016 г. той описва журналистите като “мръсни антисловашки проститутки” и ги обвинява, че се опитват да възпрепятстват европейското председателство на Словакия. Така той реагира в отговор на въпрос за предполагаеми нередности в обществените поръчки, свързани с председателството. При липсата на силни институции, които биха могли да ги защитят, журналистите в Словакия все повече са изложени на всякакъв вид тормоз, сплашване и оскърбления.

Убийството на Куцяк възобнови въпросите за необяснимото изчезване на двама журналисти, единият през 2008 г., а другият през 2015 г. и отново постави въпроса за безопасността на журналистите. През последните години словашки медии, които преди това бяха собственост на водещи международни медийни компании, бяха придобити от местни олигарси, чиито основни бизнес интереси са извън журналистиката. В момента е запллашен общественият радио и телевизионен оператор RTVS, който през последните години стана символ на журналистически интегритет.

През август 2017 г. неговият генерален директор закри единствената разследваща телевизионна програма в страната, след излъчването на критичен репортаж за по-малката партия в управляващата коалиция. Правото на отговор на критично медийното отразяване, което политиците получиха от медийния закон от 2007 г., бе ограничено в изменение от 2011 г., но клеветата все още се наказва със затвор до 8 години затвор, съгласно разпоредба на Наказателния кодекс, която политиците продължават да използват за подаване на жалби срещу индивидуални журналисти и медии.

Чехия

Трудно е да си представим президент да извади огнестрелно оръжие пред журналисти, но това направи президентът на Чешката република Милош Земан на пресконференция през октомври 2017 г., размахвайки «Калашников» с надпис “за журналисти”. Преизбран през януари 2018 г., Земан има слабост към този вид провокации и многократно е описвал журналистите като “оборска тор” и “хиени”. Президентът и няколко други политически лидери наскоро засилиха вербалните си атаки срещу независимостта на обществените медии, особено на Чешката телевизия. Също така има няколко нови законопроекти, които биха увеличили обхвата на наказателните санкции за клевета, особено клеветата срещу президента. Нивото на концентрация на собственост върху медиите стана критично, тъй като новите олигарси започнаха да използват своето богатство през 2008 г., за да купуват вестници и да засилят влиянието си. Един от тези олигарси, премиерът Андрей Бабиш, притежава един от най-влиятелните ежедневници в Чехия.

Препоръки за провеждане на бъдещи политики:

1. Журналистите, издателите, НПО и други ключови заинтересовани страни трябва да обединят усилията си за подобряване на ефективността при използването на механизми за правна защита в Съда на Европейския съюз и Европейския съд по правата на човека. Една практическа идея би могла да бъде създаването на експертно юридическо лице “Фонд за защита на свободата на медиите”, който да подпомага гражданите, независимите журналисти, издателите и медийните компании при прилагането на международните закони срещу злоупотребата с власт на местните правителства. Такъв фонд би могъл също да инициира и подкрепи независими международни разследвания на случаи на медиен натиск от високопоставени личности в държавите-членки на ЕС;

2. Европейската комисия следва да разшири новопредложената разпоредба, като обвърже отпускането на средства от ЕС не само с правовата държава и върховенството на закона, но и със свободата на медиите в държавите-членки и кандидатите. Освен върховенството на закона, комисията следва също изрично да следи за спазването на местното и европейското законодателство за нарушаване на правата на човека, свободата на изразяване, гражданското общество и функционирането на демокрацията. В страни като България, Унгария и Полша репресиите срещу свободата на медиите се правят през повечето време с правни институционални инструменти, създадени от извънредно законодателство на национално ниво.

На 3 май 2018 г. Европейският парламент гласува резолюция, споед която Комисията трябва да работи за създаването на механизъм на ЕС за демокрация, върховенство на закона и основните права, придружен от независими механизми за наблюдение, които да оценят състоянието на свободата и плурализма на медиите и всички нарушения, свързани с това.

3. Медийният бизнес модел е в преход. Икономическото оцеляване на медийните компании и независимата журналистика на по-малките пазари е много трудно. Свободните медии обаче са крайъгълният камък на гражданското общество и функционирането на демокрацията. ЕС разглежда свободната преса и свободата на изразяване като “обществено благо” и трябва да разработи обществени механизми за устойчивото си финансиране, за да гарантира своята независимост. Това би могло да включва финансиране от ЕС, насочено пряко към журналисти и медийни компании в държавите-членки, като се избягва посредничеството на местното правителство;

4. Насърчаване на иновациите и подпомагане на дигиталната трансформация на медиите в ЕС. ЕС трябва да разработи по-разнообразен инструментариум, който да помогне за преодоляване на технологичните различия между европейските медийни компании и глобалните платформи. Също така, да се насърчи предприемачеството в областта на медиите и новосъздадените компании в търсене на нови, устойчиви бизнес модели и иновативни начини за осигуряване на приходи;

5. Заинтересованите страни от ЕС и държавите членкитрябва да подкрепят категорично правото на издателите във връзка с прегледа на Директивата за авторското право, за да могат издателите да прилагат по-добре своите вече съществуващи права и да спомогнат за преговорите с основните платформи. В допълнение, трябва да се оеднаквят ставките на ДДС за печатни и онлайн издания. Освен това трябва да се гарантира, че дигиталната сфера е място, където всички участници могат да успяват, като осигурят равнопоставеност и повече баланс с технологичните гиганти и платформи. Подкрепата на професионалните медии е от съществено значение за демократичния живот и просветеността на европейските граждани и единственото дългосрочно решение за противодействие на дезинформацията.

Creating a 1.3 Million vCPU Grid on AWS using EC2 Spot Instances and TIBCO GridServer

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/creating-a-1-3-million-vcpu-grid-on-aws-using-ec2-spot-instances-and-tibco-gridserver/

Many of my colleagues are fortunate to be able to spend a good part of their day sitting down with and listening to our customers, doing their best to understand ways that we can better meet their business and technology needs. This information is treated with extreme care and is used to drive the roadmap for new services and new features.

AWS customers in the financial services industry (often abbreviated as FSI) are looking ahead to the Fundamental Review of Trading Book (FRTB) regulations that will come in to effect between 2019 and 2021. Among other things, these regulations mandate a new approach to the “value at risk” calculations that each financial institution must perform in the four hour time window after trading ends in New York and begins in Tokyo. Today, our customers report this mission-critical calculation consumes on the order of 200,000 vCPUs, growing to between 400K and 800K vCPUs in order to meet the FRTB regulations. While there’s still some debate about the magnitude and frequency with which they’ll need to run this expanded calculation, the overall direction is clear.

Building a Big Grid
In order to make sure that we are ready to help our FSI customers meet these new regulations, we worked with TIBCO to set up and run a proof of concept grid in the AWS Cloud. The periodic nature of the calculation, along with the amount of processing power and storage needed to run it to completion within four hours, make it a great fit for an environment where a vast amount of cost-effective compute power is available on an on-demand basis.

Our customers are already using the TIBCO GridServer on-premises and want to use it in the cloud. This product is designed to run grids at enterprise scale. It runs apps in a virtualized fashion, and accepts requests for resources, dynamically provisioning them on an as-needed basis. The cloud version supports Amazon Linux as well as the PostgreSQL-compatible edition of Amazon Aurora.

Working together with TIBCO, we set out to create a grid that was substantially larger than the current high-end prediction of 800K vCPUs, adding a 50% safety factor and then rounding up to reach 1.3 million vCPUs (5x the size of the largest on-premises grid). With that target in mind, the account limits were raised as follows:

  • Spot Instance Limit – 120,000
  • EBS Volume Limit – 120,000
  • EBS Capacity Limit – 2 PB

If you plan to create a grid of this size, you should also bring your friendly local AWS Solutions Architect into the loop as early as possible. They will review your plans, provide you with architecture guidance, and help you to schedule your run.

Running the Grid
We hit the Go button and launched the grid, watching as it bid for and obtained Spot Instances, each of which booted, initialized, and joined the grid within two minutes. The test workload used the Strata open source analytics & market risk library from OpenGamma and was set up with their assistance.

The grid grew to 61,299 Spot Instances (1.3 million vCPUs drawn from 34 instance types spanning 3 generations of EC2 hardware) as planned, with just 1,937 instances reclaimed and automatically replaced during the run, and cost $30,000 per hour to run, at an average hourly cost of $0.078 per vCPU. If the same instances had been used in On-Demand form, the hourly cost to run the grid would have been approximately $93,000.

Despite the scale of the grid, prices for the EC2 instances did not move during the bidding process. This is due to the overall size of the AWS Cloud and the smooth price change model that we launched late last year.

To give you a sense of the compute power, we computed that this grid would have taken the #1 position on the TOP 500 supercomputer list in November 2007 by a considerable margin, and the #2 position in June 2008. Today, it would occupy position #360 on the list.

I hope that you enjoyed this AWS success story, and that it gives you an idea of the scale that you can achieve in the cloud!

Jeff;

Engineering deep dive: Encoding of SCTs in certificates

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org/2018/04/04/sct-encoding.html

<p>Let&rsquo;s Encrypt recently <a href="https://community.letsencrypt.org/t/signed-certificate-timestamps-embedded-in-certificates/57187">launched SCT embedding in
certificates</a>.
This feature allows browsers to check that a certificate was submitted to a
<a href="https://en.wikipedia.org/wiki/Certificate_Transparency">Certificate Transparency</a>
log. As part of the launch, we did a thorough review
that the encoding of Signed Certificate Timestamps (SCTs) in our certificates
matches the relevant specifications. In this post, I&rsquo;ll dive into the details.
You&rsquo;ll learn more about X.509, ASN.1, DER, and TLS encoding, with references to
the relevant RFCs.</p>

<p>Certificate Transparency offers three ways to deliver SCTs to a browser: In a
TLS extension, in stapled OCSP, or embedded in a certificate. We chose to
implement the embedding method because it would just work for Let&rsquo;s Encrypt
subscribers without additional work. In the SCT embedding method, we submit
a &ldquo;precertificate&rdquo; with a <a href="#poison">poison extension</a> to a set of
CT logs, and get back SCTs. We then issue a real certificate based on the
precertificate, with two changes: The poison extension is removed, and the SCTs
obtained earlier are added in another extension.</p>

<p>Given a certificate, let&rsquo;s first look for the SCT list extension. According to CT (<a href="https://tools.ietf.org/html/rfc6962#section-3.3">RFC 6962
section 3.3</a>),
the extension OID for a list of SCTs is <code>1.3.6.1.4.1.11129.2.4.2</code>. An <a href="http://www.hl7.org/Oid/information.cfm">OID (object
ID)</a> is a series of integers, hierarchically
assigned and globally unique. They are used extensively in X.509, for instance
to uniquely identify extensions.</p>

<p>We can <a href="https://acme-v01.api.letsencrypt.org/acme/cert/031f2484307c9bc511b3123cb236a480d451">download an example certificate</a>,
and view it using OpenSSL (if your OpenSSL is old, it may not display the
detailed information):</p>

<pre><code>$ openssl x509 -noout -text -inform der -in Downloads/031f2484307c9bc511b3123cb236a480d451

CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1(0)
Log ID : DB:74:AF:EE:CB:29:EC:B1:FE:CA:3E:71:6D:2C:E5:B9:
AA:BB:36:F7:84:71:83:C7:5D:9D:4F:37:B6:1F:BF:64
Timestamp : Mar 29 18:45:07.993 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:7E:1F:CD:1E:9A:2B:D2:A5:0A:0C:81:E7:
13:03:3A:07:62:34:0D:A8:F9:1E:F2:7A:48:B3:81:76:
40:15:9C:D3:02:20:65:9F:E9:F1:D8:80:E2:E8:F6:B3:
25:BE:9F:18:95:6D:17:C6:CA:8A:6F:2B:12:CB:0F:55:
FB:70:F7:59:A4:19
Signed Certificate Timestamp:
Version : v1(0)
Log ID : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
Timestamp : Mar 29 18:45:08.010 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:AB:72:F1:E4:D6:22:3E:F8:7F:C6:84:
91:C2:08:D2:9D:4D:57:EB:F4:75:88:BB:75:44:D3:2F:
95:37:E2:CE:C1:02:21:00:8A:FF:C4:0C:C6:C4:E3:B2:
45:78:DA:DE:4F:81:5E:CB:CE:2D:57:A5:79:34:21:19:
A1:E6:5B:C7:E5:E6:9C:E2
</code></pre>

<p>Now let&rsquo;s go a little deeper. How is that extension represented in
the certificate? Certificates are expressed in
<a href="https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One">ASN.1</a>,
which generally refers to both a language for expressing data structures
and a set of formats for encoding them. The most common format,
<a href="https://en.wikipedia.org/wiki/X.690#DER_encoding">DER</a>,
is a tag-length-value format. That is, to encode an object, first you write
down a tag representing its type (usually one byte), then you write
down a number expressing how long the object is, then you write down
the object contents. This is recursive: An object can contain multiple
objects within it, each of which has its own tag, length, and value.</p>

<p>One of the cool things about DER and other tag-length-value formats is that you
can decode them to some degree without knowing what they mean. For instance, I
can tell you that 0x30 means the data type &ldquo;SEQUENCE&rdquo; (a struct, in ASN.1
terms), and 0x02 means &ldquo;INTEGER&rdquo;, then give you this hex byte sequence to
decode:</p>

<pre><code>30 06 02 01 03 02 01 0A
</code></pre>

<p>You could tell me right away that decodes to:</p>

<pre><code>SEQUENCE
INTEGER 3
INTEGER 10
</code></pre>

<p>Try it yourself with this great <a href="https://lapo.it/asn1js/#300602010302010A">JavaScript ASN.1
decoder</a>. However, you wouldn&rsquo;t know
what those integers represent without the corresponding ASN.1 schema (or
&ldquo;module&rdquo;). For instance, if you knew that this was a piece of DogData, and the
schema was:</p>

<pre><code>DogData ::= SEQUENCE {
legs INTEGER,
cutenessLevel INTEGER
}
</code></pre>

<p>You&rsquo;d know this referred to a three-legged dog with a cuteness level of 10.</p>

<p>We can take some of this knowledge and apply it to our certificates. As a first
step, convert the above certificate to hex with
<code>xxd -ps &lt; Downloads/031f2484307c9bc511b3123cb236a480d451</code>. You can then copy
and paste the result into
<a href="https://lapo.it/asn1js">lapo.it/asn1js</a> (or use <a href="https://lapo.it/asn1js/#3082062F30820517A0030201020212031F2484307C9BC511B3123CB236A480D451300D06092A864886F70D01010B0500304A310B300906035504061302555331163014060355040A130D4C6574277320456E6372797074312330210603550403131A4C6574277320456E637279707420417574686F72697479205833301E170D3138303332393137343530375A170D3138303632373137343530375A302D312B3029060355040313223563396137662E6C652D746573742E686F66666D616E2D616E64726577732E636F6D30820122300D06092A864886F70D01010105000382010F003082010A0282010100BCEAE8F504D9D91FCFC69DB943254A7FED7C6A3C04E2D5C7DDD010CBBC555887274489CA4F432DCE6D7AB83D0D7BDB49C466FBCA93102DC63E0EB1FB2A0C50654FD90B81A6CB357F58E26E50F752BF7BFE9B56190126A47409814F59583BDD337DFB89283BE22E81E6DCE13B4E21FA6009FC8A7F903A17AB05C8BED85A715356837E849E571960A8999701EAE9CE0544EAAB936B790C3C35C375DB18E9AA627D5FA3579A0FB5F8079E4A5C9BE31C2B91A7F3A63AFDFEDB9BD4EA6668902417D286BE4BBE5E43CD9FE1B8954C06F21F5C5594FD3AB7D7A9CBD6ABF19774D652FD35C5718C25A3BA1967846CED70CDBA95831CF1E09FF7B8014E63030CE7A776750203010001A382032A30820326300E0603551D0F0101FF0404030205A0301D0603551D250416301406082B0601050507030106082B06010505070302300C0603551D130101FF04023000301D0603551D0E041604148B3A21ABADF50C4B30DCCD822724D2C4B9BA29E3301F0603551D23041830168014A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1306F06082B0601050507010104633061302E06082B060105050730018622687474703A2F2F6F6373702E696E742D78332E6C657473656E63727970742E6F7267302F06082B060105050730028623687474703A2F2F636572742E696E742D78332E6C657473656E63727970742E6F72672F302D0603551D110426302482223563396137662E6C652D746573742E686F66666D616E2D616E64726577732E636F6D3081FE0603551D200481F63081F33008060667810C0102013081E6060B2B0601040182DF130101013081D6302606082B06010505070201161A687474703A2F2F6370732E6C657473656E63727970742E6F72673081AB06082B0601050507020230819E0C819B54686973204365727469666963617465206D6179206F6E6C792062652072656C6965642075706F6E2062792052656C79696E67205061727469657320616E64206F6E6C7920696E206163636F7264616E636520776974682074686520436572746966696361746520506F6C69637920666F756E642061742068747470733A2F2F6C657473656E63727970742E6F72672F7265706F7369746F72792F30820104060A2B06010401D6790204020481F50481F200F0007500DB74AFEECB29ECB1FECA3E716D2CE5B9AABB36F7847183C75D9D4F37B61FBF64000001627313EB19000004030046304402207E1FCD1E9A2BD2A50A0C81E713033A0762340DA8F91EF27A48B3817640159CD30220659FE9F1D880E2E8F6B325BE9F18956D17C6CA8A6F2B12CB0F55FB70F759A419007700293C519654C83965BAAA50FC5807D4B76FBF587A2972DCA4C30CF4E54547F478000001627313EB2A0000040300483046022100AB72F1E4D6223EF87FC68491C208D29D4D57EBF47588BB7544D32F9537E2CEC10221008AFFC40CC6C4E3B24578DADE4F815ECBCE2D57A579342119A1E65BC7E5E69CE2300D06092A864886F70D01010B0500038201010095F87B663176776502F792DDD232C216943C7803876FCBEB46393A36354958134482E0AFEED39011618327C2F0203351758FEB420B73CE6C797B98F88076F409F3903F343D1F5D9540F41EF47EB39BD61B62873A44F00B7C8B593C6A416458CF4B5318F35235BC88EABBAA34F3E3F81BD3B047E982EE1363885E84F76F2F079F2B6EEB4ECB58EFE74C8DE7D54DE5C89C4FB5BB0694B837BD6F02BAFD5A6C007D1B93D25007BDA9B2BDBF82201FE1B76B628CE34E2D974E8E623EC57A5CB53B435DD4B9993ADF6BA3972F2B29D259594A94E17BBE06F34AAE5CF0F50297548C4DFFC5566136F78A3D3B324EAE931A14EB6BE6DA1D538E48CF077583C67B52E7E8">this handy link</a>). You can also run <code>openssl asn1parse -i -inform der -in Downloads/031f2484307c9bc511b3123cb236a480d451</code> to use OpenSSL&rsquo;s parser, which is less easy to use in some ways, but easier to copy and paste.</p>

<p>In the decoded data, we can find the OID <code>1.3.6.1.4.1.11129.2.4.2</code>, indicating
the SCT list extension. Per <a href="https://tools.ietf.org/html/rfc5280#page-17">RFC 5280, section
4.1</a>, an extension is defined:</p>

<pre><code>Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
— contains the DER encoding of an ASN.1 value
— corresponding to the extension type identified
— by extnID
}
</code></pre>

<p>We&rsquo;ve found the <code>extnID</code>. The &ldquo;critical&rdquo; field is omitted because it has the
default value (false). Next up is the <code>extnValue</code>. This has the type
<code>OCTET STRING</code>, which has the tag &ldquo;0x04&rdquo;. <code>OCTET STRING</code> means &ldquo;here&rsquo;s
a bunch of bytes!&rdquo; In this case, as described by the spec, those bytes
happen to contain more DER. This is a fairly common pattern in X.509
to deal with parameterized data. For instance, this allows defining a
structure for extensions without knowing ahead of time all the structures
that a future extension might want to carry in its value. If you&rsquo;re a C
programmer, think of it as a <code>void*</code> for data structures. If you prefer Go,
think of it as an <code>interface{}</code>.</p>

<p>Here&rsquo;s that <code>extnValue</code>:</p>

<pre><code>04 81 F5 0481F200F0007500DB74AFEECB29ECB1FECA3E716D2CE5B9AABB36F7847183C75D9D4F37B61FBF64000001627313EB19000004030046304402207E1FCD1E9A2BD2A50A0C81E713033A0762340DA8F91EF27A48B3817640159CD30220659FE9F1D880E2E8F6B325BE9F18956D17C6CA8A6F2B12CB0F55FB70F759A419007700293C519654C83965BAAA50FC5807D4B76FBF587A2972DCA4C30CF4E54547F478000001627313EB2A0000040300483046022100AB72F1E4D6223EF87FC68491C208D29D4D57EBF47588BB7544D32F9537E2CEC10221008AFFC40CC6C4E3B24578DADE4F815ECBCE2D57A579342119A1E65BC7E5E69CE2
</code></pre>

<p>That&rsquo;s tag &ldquo;0x04&rdquo;, meaning <code>OCTET STRING</code>, followed by &ldquo;0x81 0xF5&rdquo;, meaning
&ldquo;this string is 245 bytes long&rdquo; (the 0x81 prefix is part of <a href="#variable-length">variable length
number encoding</a>).</p>

<p>According to <a href="https://tools.ietf.org/html/rfc6962#section-3.3">RFC 6962, section
3.3</a>, &ldquo;obtained SCTs
can be directly embedded in the final certificate, by encoding the
SignedCertificateTimestampList structure as an ASN.1 <code>OCTET STRING</code>
and inserting the resulting data in the TBSCertificate as an X.509v3
certificate extension&rdquo;</p>

<p>So, we have an <code>OCTET STRING</code>, all&rsquo;s good, right? Except if you remove the
tag and length from extnValue to get its value, you&rsquo;re left with:</p>

<pre><code>04 81 F2 00F0007500DB74AFEEC…
</code></pre>

<p>There&rsquo;s that &ldquo;0x04&rdquo; tag again, but with a shorter length. Why
do we nest one <code>OCTET STRING</code> inside another? It&rsquo;s because the
contents of extnValue are required by RFC 5280 to be valid DER, but a
SignedCertificateTimestampList is not encoded using DER (more on that
in a minute). So, by RFC 6962, a SignedCertificateTimestampList is wrapped in an
<code>OCTET STRING</code>, which is wrapped in another <code>OCTET STRING</code> (the extnValue).</p>

<p>Once we decode that second <code>OCTET STRING</code>, we&rsquo;re left with the contents:</p>

<pre><code>00F0007500DB74AFEEC…
</code></pre>

<p>&ldquo;0x00&rdquo; isn&rsquo;t a valid tag in DER. What is this? It&rsquo;s TLS encoding. This is
defined in <a href="https://tools.ietf.org/html/rfc5246#section-4">RFC 5246, section 4</a>
(the TLS 1.2 RFC). TLS encoding, like ASN.1, has both a way to define data
structures and a way to encode those structures. TLS encoding differs
from DER in that there are no tags, and lengths are only encoded when necessary for
variable-length arrays. Within an encoded structure, the type of a field is determined by
its position, rather than by a tag. This means that TLS-encoded structures are
more compact than DER structures, but also that they can&rsquo;t be processed without
knowing the corresponding schema. For instance, here&rsquo;s the top-level schema from
<a href="https://tools.ietf.org/html/rfc6962#section-3.3">RFC 6962, section 3.3</a>:</p>

<pre><code> The contents of the ASN.1 OCTET STRING embedded in an OCSP extension
or X509v3 certificate extension are as follows:

opaque SerializedSCT&lt;1..2^16-1&gt;;

struct {
SerializedSCT sct_list &lt;1..2^16-1&gt;;
} SignedCertificateTimestampList;

Here, &quot;SerializedSCT&quot; is an opaque byte string that contains the
serialized TLS structure.
</code></pre>

<p>Right away, we&rsquo;ve found one of those variable-length arrays. The length of such
an array (in bytes) is always represented by a length field just big enough to
hold the max array size. The max size of an <code>sct_list</code> is 65535 bytes, so the
length field is two bytes wide. Sure enough, those first two bytes are &ldquo;0x00
0xF0&rdquo;, or 240 in decimal. In other words, this <code>sct_list</code> will have 240 bytes. We
don&rsquo;t yet know how many SCTs will be in it. That will become clear only by
continuing to parse the encoded data and seeing where each struct ends (spoiler
alert: there are two SCTs!).</p>

<p>Now we know the first SerializedSCT starts with <code>0075…</code>. SerializedSCT
is itself a variable-length field, this time containing <code>opaque</code> bytes (much like <code>OCTET STRING</code>
back in the ASN.1 world). Like SignedCertificateTimestampList, it has a max size
of 65535 bytes, so we pull off the first two bytes and discover that the first
SerializedSCT is 0x0075 (117 decimal) bytes long. Here&rsquo;s the whole thing, in
hex:</p>

<pre><code>00DB74AFEECB29ECB1FECA3E716D2CE5B9AABB36F7847183C75D9D4F37B61FBF64000001627313EB19000004030046304402207E1FCD1E9A2BD2A50A0C81E713033A0762340DA8F91EF27A48B3817640159CD30220659FE9F1D880E2E8F6B325BE9F18956D17C6CA8A6F2B12CB0F55FB70F759A419
</code></pre>

<p>This can be decoded using the TLS encoding struct defined in <a href="https://tools.ietf.org/html/rfc6962#page-13">RFC 6962, section
3.2</a>:</p>

<pre><code>enum { v1(0), (255) }
Version;

struct {
opaque key_id[32];
} LogID;

opaque CtExtensions&lt;0..2^16-1&gt;;

struct {
Version sct_version;
LogID id;
uint64 timestamp;
CtExtensions extensions;
digitally-signed struct {
Version sct_version;
SignatureType signature_type = certificate_timestamp;
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
};
} SignedCertificateTimestamp;
</code></pre>

<p>Breaking that down:</p>

<pre><code># Version sct_version v1(0)
00
# LogID id (aka opaque key_id[32])
DB74AFEECB29ECB1FECA3E716D2CE5B9AABB36F7847183C75D9D4F37B61FBF64
# uint64 timestamp (milliseconds since the epoch)
000001627313EB19
# CtExtensions extensions (zero-length array)
0000
# digitally-signed struct
04030046304402207E1FCD1E9A2BD2A50A0C81E713033A0762340DA8F91EF27A48B3817640159CD30220659FE9F1D880E2E8F6B325BE9F18956D17C6CA8A6F2B12CB0F55FB70F759A419
</code></pre>

<p>To understand the &ldquo;digitally-signed struct,&rdquo; we need to turn back to <a href="https://tools.ietf.org/html/rfc5246#section-4.7">RFC 5246,
section 4.7</a>. It says:</p>

<pre><code>A digitally-signed element is encoded as a struct DigitallySigned:

struct {
SignatureAndHashAlgorithm algorithm;
opaque signature&lt;0..2^16-1&gt;;
} DigitallySigned;
</code></pre>

<p>And in <a href="https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1">section
7.4.1.4.1</a>:</p>

<pre><code>enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;

enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm;

struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
</code></pre>

<p>We have &ldquo;0x0403&rdquo;, which corresponds to sha256(4) and ecdsa(3). The next two
bytes, &ldquo;0x0046&rdquo;, tell us the length of the &ldquo;opaque signature&rdquo; field, 70 bytes in
decimal. To decode the signature, we reference <a href="https://tools.ietf.org/html/rfc4492#page-20">RFC 4492 section
5.4</a>, which says:</p>

<pre><code>The digitally-signed element is encoded as an opaque vector &lt;0..2^16-1&gt;, the
contents of which are the DER encoding corresponding to the
following ASN.1 notation.

Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
</code></pre>

<p>Having dived through two layers of TLS encoding, we are now back in ASN.1 land!
We
<a href="https://lapo.it/asn1js/#304402207E1FCD1E9A2BD2A50A0C81E713033A0762340DA8F91EF27A48B3817640159CD30220659FE9F1D880E2E8F6B325BE9F18956D17C6CA8A6F2B12CB0F55FB70F759A419">decode</a>
the remaining bytes into a SEQUENCE containing two INTEGERS. And we&rsquo;re done! Here&rsquo;s the whole
extension decoded:</p>

<pre><code># Extension SEQUENCE – RFC 5280
30
# length 0x0104 bytes (260 decimal)
820104
# OBJECT IDENTIFIER
06
# length 0x0A bytes (10 decimal)
0A
# value (1.3.6.1.4.1.11129.2.4.2)
2B06010401D679020402
# OCTET STRING
04
# length 0xF5 bytes (245 decimal)
81F5
# OCTET STRING (embedded) – RFC 6962
04
# length 0xF2 bytes (242 decimal)
81F2
# Beginning of TLS encoded SignedCertificateTimestampList – RFC 5246 / 6962
# length 0xF0 bytes
00F0
# opaque SerializedSCT&lt;1..2^16-1&gt;
# length 0x75 bytes
0075
# Version sct_version v1(0)
00
# LogID id (aka opaque key_id[32])
DB74AFEECB29ECB1FECA3E716D2CE5B9AABB36F7847183C75D9D4F37B61FBF64
# uint64 timestamp (milliseconds since the epoch)
000001627313EB19
# CtExtensions extensions (zero-length array)
0000
# digitally-signed struct – RFC 5426
# SignatureAndHashAlgorithm (ecdsa-sha256)
0403
# opaque signature&lt;0..2^16-1&gt;;
# length 0x0046
0046
# DER-encoded Ecdsa-Sig-Value – RFC 4492
30 # SEQUENCE
44 # length 0x44 bytes
02 # r INTEGER
20 # length 0x20 bytes
# value
7E1FCD1E9A2BD2A50A0C81E713033A0762340DA8F91EF27A48B3817640159CD3
02 # s INTEGER
20 # length 0x20 bytes
# value
659FE9F1D880E2E8F6B325BE9F18956D17C6CA8A6F2B12CB0F55FB70F759A419
# opaque SerializedSCT&lt;1..2^16-1&gt;
# length 0x77 bytes
0077
# Version sct_version v1(0)
00
# LogID id (aka opaque key_id[32])
293C519654C83965BAAA50FC5807D4B76FBF587A2972DCA4C30CF4E54547F478
# uint64 timestamp (milliseconds since the epoch)
000001627313EB2A
# CtExtensions extensions (zero-length array)
0000
# digitally-signed struct – RFC 5426
# SignatureAndHashAlgorithm (ecdsa-sha256)
0403
# opaque signature&lt;0..2^16-1&gt;;
# length 0x0048
0048
# DER-encoded Ecdsa-Sig-Value – RFC 4492
30 # SEQUENCE
46 # length 0x46 bytes
02 # r INTEGER
21 # length 0x21 bytes
# value
00AB72F1E4D6223EF87FC68491C208D29D4D57EBF47588BB7544D32F9537E2CEC1
02 # s INTEGER
21 # length 0x21 bytes
# value
008AFFC40CC6C4E3B24578DADE4F815ECBCE2D57A579342119A1E65BC7E5E69CE2
</code></pre>

<p>One surprising thing you might notice: In the first SCT, <code>r</code> and <code>s</code> are twenty
bytes long. In the second SCT, they are both twenty-one bytes long, and have a
leading zero. Integers in DER are two&rsquo;s complement, so if the leftmost bit is
set, they are interpreted as negative. Since <code>r</code> and <code>s</code> are positive, if the
leftmost bit would be a 1, an extra byte has to be added so that the leftmost
bit can be 0.</p>

<p>This is a little taste of what goes into encoding a certificate. I hope it was
informative! If you&rsquo;d like to learn more, I recommend &ldquo;<a href="http://luca.ntop.org/Teaching/Appunti/asn1.html">A Layman&rsquo;s Guide to a
Subset of ASN.1, BER, and DER</a>.&rdquo;</p>

<p><a name="poison"></a>Footnote 1: A &ldquo;poison extension&rdquo; is defined by <a href="https://tools.ietf.org/html/rfc6962#section-3.1">RFC 6962
section 3.1</a>:</p>

<pre><code>The Precertificate is constructed from the certificate to be issued by adding a special
critical poison extension (OID `1.3.6.1.4.1.11129.2.4.3`, whose
extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00))
</code></pre>

<p>In other words, it&rsquo;s an empty extension whose only purpose is to ensure that
certificate processors will not accept precertificates as valid certificates. The
specification ensures this by setting the &ldquo;critical&rdquo; bit on the extension, which
ensures that code that doesn&rsquo;t recognize the extension will reject the whole
certificate. Code that does recognize the extension specifically as poison
will also reject the certificate.</p>

<p><a name="variable-length"></a>Footnote 2: Lengths from 0-127 are represented by
a single byte (short form). To express longer lengths, more bytes are used (long form).
The high bit (0x80) on the first byte is set to distinguish long form from short
form. The remaining bits are used to express how many more bytes to read for the
length. For instance, 0x81F5 means &ldquo;this is long form because the length is
greater than 127, but there&rsquo;s still only one byte of length (0xF5) to decode.&rdquo;</p>

Looking Forward to 2018

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html

<p>Let’s Encrypt had a great year in 2017. We more than doubled the number of active (unexpired) certificates we service to 46 million, we just about tripled the number of unique domains we service to 61 million, and we did it all while maintaining a stellar security and compliance track record. Most importantly though, <a href="https://letsencrypt.org/stats/">the Web went from 46% encrypted page loads to 67%</a> according to statistics from Mozilla – a gain of 21 percentage points in a single year – incredible. We’re proud to have contributed to that, and we’d like to thank all of the other people and organizations who also worked hard to create a more secure and privacy-respecting Web.</p>

<p>While we’re proud of what we accomplished in 2017, we are spending most of the final quarter of the year looking forward rather than back. As we wrap up our own planning process for 2018, I’d like to share some of our plans with you, including both the things we’re excited about and the challenges we’ll face. We’ll cover service growth, new features, infrastructure, and finances.</p>

<h1 id="service-growth">Service Growth</h1>

<p>We are planning to double the number of active certificates and unique domains we service in 2018, to 90 million and 120 million, respectively. This anticipated growth is due to continuing high expectations for HTTPS growth in general in 2018.</p>

<p>Let’s Encrypt helps to drive HTTPS adoption by offering a free, easy to use, and globally available option for obtaining the certificates required to enable HTTPS. HTTPS adoption on the Web took off at an unprecedented rate from the day Let’s Encrypt launched to the public.</p>

<p>One of the reasons Let’s Encrypt is so easy to use is that our community has done great work making client software that works well for a wide variety of platforms. We’d like to thank everyone involved in the development of over 60 <a href="https://letsencrypt.org/docs/client-options/">client software options for Let’s Encrypt</a>. We’re particularly excited that support for the ACME protocol and Let’s Encrypt is <a href="https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html">being added to the Apache httpd server</a>.</p>

<p>Other organizations and communities are also doing great work to promote HTTPS adoption, and thus stimulate demand for our services. For example, browsers are starting to make their users more aware of the risks associated with unencrypted HTTP (e.g. <a href="https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/">Firefox</a>, <a href="https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html">Chrome</a>). Many hosting providers and CDNs are making it easier than ever for all of their customers to use HTTPS. <a href="https://https.cio.gov/">Government</a> <a href="https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/strategic-plan-2017-2021.html#toc8-3-2">agencies</a> are waking up to the need for stronger security to protect constituents. The media community is working to <a href="https://securethe.news/">Secure the News</a>.</p>

<h1 id="new-features">New Features</h1>

<p>We’ve got some exciting features planned for 2018.</p>

<p>First, we’re planning to introduce an ACME v2 protocol API endpoint and <a href="https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html">support for wildcard certificates</a> along with it. Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.</p>

<p>Later in 2018 we plan to introduce ECDSA root and intermediate certificates. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let’s Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.</p>

<h1 id="infrastructure">Infrastructure</h1>

<p>Our CA infrastructure is capable of issuing millions of certificates per day with multiple redundancy for stability and a wide variety of security safeguards, both physical and logical. Our infrastructure also generates and signs nearly 20 million OCSP responses daily, and serves those responses nearly 2 billion times per day. We expect issuance and OCSP numbers to double in 2018.</p>

<p>Our physical CA infrastructure currently occupies approximately 70 units of rack space, split between two datacenters, consisting primarily of compute servers, storage, HSMs, switches, and firewalls.</p>

<p>When we issue more certificates it puts the most stress on storage for our databases. We regularly invest in more and faster storage for our database servers, and that will continue in 2018.</p>

<p>We’ll need to add a few additional compute servers in 2018, and we’ll also start aging out hardware in 2018 for the first time since we launched. We’ll age out about ten 2u compute servers and replace them with new 1u servers, which will save space and be more energy efficient while providing better reliability and performance.</p>

<p>We’ll also add another infrastructure operations staff member, bringing that team to a total of six people. This is necessary in order to make sure we can keep up with demand while maintaining a high standard for security and compliance. Infrastructure operations staff are systems administrators responsible for building and maintaining all physical and logical CA infrastructure. The team also manages a 24/7/365 on-call schedule and they are primary participants in both security and compliance audits.</p>

<h1 id="finances">Finances</h1>

<p>We pride ourselves on being an efficient organization. In 2018 Let’s Encrypt will secure a large portion of the Web with a budget of only $3.0M. For an overall increase in our budget of only 13%, we will be able to issue and service twice as many certificates as we did in 2017. We believe this represents an incredible value and that contributing to Let’s Encrypt is one of the most effective ways to help create a more secure and privacy-respecting Web.</p>

<p>Our 2018 fundraising efforts are off to a strong start with Platinum sponsorships from Mozilla, Akamai, OVH, Cisco, Google Chrome and the Electronic Frontier Foundation. The Ford Foundation has renewed their grant to Let’s Encrypt as well. We are seeking additional sponsorship and grant assistance to meet our full needs for 2018.</p>

<p>We had originally budgeted $2.91M for 2017 but we’ll likely come in under budget for the year at around $2.65M. The difference between our 2017 expenses of $2.65M and the 2018 budget of $3.0M consists primarily of the additional infrastructure operations costs previously mentioned.</p>

<h1 id="support-let-s-encrypt">Support Let’s Encrypt</h1>

<p>We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to <a href="https://letsencrypt.org/become-a-sponsor/">sponsor</a> Let’s Encrypt please email us at <a href="mailto:[email protected]">[email protected]</a>. We ask that you make an <a href="https://letsencrypt.org/donate/">individual contribution</a> if it is within your means.</p>

<p>We’re grateful for the industry and community support that we receive, and we look forward to continuing to create a more secure and privacy-respecting Web!</p>

Announcing Amazon FreeRTOS – Enabling Billions of Devices to Securely Benefit from the Cloud

Post Syndicated from Tara Walker original https://aws.amazon.com/blogs/aws/announcing-amazon-freertos/

I was recently reading an article on ReadWrite.com titled “IoT devices go forth and multiply, to increase 200% by 2021“, and while the article noted the benefit for consumers and the industry of this growth, two things in the article stuck with me. The first was the specific statement that read “researchers warned that the proliferation of IoT technology will create a new bevvy of challenges. Particularly troublesome will be IoT deployments at scale for both end-users and providers.” Not only was that sentence a mouthful, but it really addressed some of the challenges that can come building solutions and deployment of this exciting new technology area. The second sentiment in the article that stayed with me was that Security issues could grow.

So the article got me thinking, how can we create these cool IoT solutions using low-cost efficient microcontrollers with a secure operating system that can easily connect to the cloud. Luckily the answer came to me by way of an exciting new open-source based offering coming from AWS that I am happy to announce to you all today. Let’s all welcome, Amazon FreeRTOS to the technology stage.

Amazon FreeRTOS is an IoT microcontroller operating system that simplifies development, security, deployment, and maintenance of microcontroller-based edge devices. Amazon FreeRTOS extends the FreeRTOS kernel, a popular real-time operating system, with libraries that enable local and cloud connectivity, security, and (coming soon) over-the-air updates.

So what are some of the great benefits of this new exciting offering, you ask. They are as follows:

  • Easily to create solutions for Low Power Connected Devices: provides a common operating system (OS) and libraries that make the development of common IoT capabilities easy for devices. For example; over-the-air (OTA) updates (coming soon) and device configuration.
  • Secure Data and Device Connections: devices only run trusted software using the Code Signing service, Amazon FreeRTOS provides a secure connection to the AWS using TLS, as well as, the ability to securely store keys and sensitive data on the device.
  • Extensive Ecosystem: contains an extensive hardware and technology ecosystem that allows you to choose a variety of qualified chipsets, including Texas Instruments, Microchip, NXP Semiconductors, and STMicroelectronics.
  • Cloud or Local Connections:  Devices can connect directly to the AWS Cloud or via AWS Greengrass.

 

What’s cool is that it is easy to get started. 

The Amazon FreeRTOS console allows you to select and download the software that you need for your solution.

There is a Qualification Program that helps to assure you that the microcontroller you choose will run consistently across several hardware options.

Finally, Amazon FreeRTOS kernel is an open-source FreeRTOS operating system that is freely available on GitHub for download.

But I couldn’t leave you without at least showing you a few snapshots of the Amazon FreeRTOS Console.

Within the Amazon FreeRTOS Console, I can select a predefined software configuration that I would like to use.

If I want to have a more customized software configuration, Amazon FreeRTOS allows you to customize a solution that is targeted for your use by adding or removing libraries.

Summary

Thanks for checking out the new Amazon FreeRTOS offering. To learn more go to the Amazon FreeRTOS product page or review the information provided about this exciting IoT device targeted operating system in the AWS documentation.

Can’t wait to see what great new IoT systems are will be enabled and created with it! Happy Coding.

Tara

 

Linux Mint 18.3 released

Post Syndicated from ris original https://lwn.net/Articles/740058/rss

Linux Mint has released 18.3 “Sylvia” in Cinnamon and MATE editions. Linux Mint
18.3 is a long term support release which will be supported until 2021.
Both editions feature a revamped Software Manager with support for
flatpaks. See more about what’s new in the Cinnamon
and MATE
editions or check out the release notes for Cinnamon and
MATE.

In the Works – AWS Region in the Middle East

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-the-middle-east/

Last year we launched new AWS Regions in Canada, India, Korea, the UK, and the United States, and announced that new regions are coming to China, France, Hong Kong, Sweden, and a second GovCloud Region in the US throughout 2017 and 2018.

Middle East Region by Early 2019
Today, I am happy to announce that we will be opening an AWS Region in the Middle East by early 2019. The new Region will be based in Bahrain, will be comprised of three Availability Zones at launch, and will give AWS customers and partners the ability to run their workloads and store their data in the Middle East.

AWS customers are already making use of 44 Availability Zones across 16 geographic regions. Today’s announcement brings the total number of global regions (operational and in the works) up to 22.

UAE Edge Location in 2018
We also plan to open an edge location in the UAE in the first quarter of 2018. This will bring Amazon CloudFront, Amazon Route 53, AWS Shield, and AWS WAF to the region, adding to our existing set of 78 points of presence world-wide.

These announcements add to our continued investment in the Middle East. Earlier this year we announced the opening of AWS offices in Dubai, UAE and Manama, Bahrain. Prior to this we have supported the growth of technology education in the region with AWS Educate and have supported the growth of new businesses through AWS Activate for many years.

The addition of AWS infrastructure in the Middle East will help countries across the region to innovate, grow their economies, and pursue their vision plans (Saudi Vision 2030, UAE Vision 2021, Bahrain Vision 2030, and so forth).

Talk to Us
As always, we are looking forward to serving new and existing customers in the Middle East and working with partners across the region. Of course, the new Region will also be open to existing AWS customers who would like to serve users in the Middle East.

To learn more about the AWS Middle East Region feel free to contact our team at [email protected] .

If you are interested in joining the team and would like to learn more about AWS positions in the Middle East, take a look at the Amazon Jobs site.

Jeff;